1) Legacy systems are older software systems that have been in use for a long time and are often critical to business operations. 2) They were often developed years ago using outdated technologies and have evolved over many years of customizations and changes. 3) Replacing legacy systems carries significant business risks due to a lack of complete documentation and embedded business rules not formally documented elsewhere. Changing legacy systems can also be very expensive.

1. Types of software products
1

2. Syllabus: Unit 1
• Role of Software Engineering, Software Evolution,
Legacy system structures, Legacy system design,
Legacy System Assessment, Software Development
Life Cycle.
2

3. Difference between generic and customized software
• The generic software product specifications are
produced internally by the marketing department of the
product company. They reflect what they think will sell.
They are usually flexible and non-prescriptive.
• For customized systems are often the basis for the
contract between customer and developer. They are
usually defined in detail and changes have to be
negotiated and carefully costed.
3

4. What are the main ingredients of
Software Engineering.
4

5. What are the main ingredients of
Software Engineering
• Principle
• Methods and Techniques
• Methodology
• Tools
• How above are correlated…
5

6. • Relationship Between Principal, Methods and
Techniques, Methodology and Tools
6

7. What are the key challenges facing
software engineering?
7

8. What are the key challenges facing
software engineering?
• Heterogeneity, delivery and trust.
• Heterogeneity
– Developing techniques for building software that can cope with
heterogeneous platforms and execution environments;
• Delivery
– Developing techniques that lead to faster delivery of software;
• Trust
– Developing techniques that demonstrate that software can be trusted by its
users.
8

9. SOFTWARE EVOLUTION
9

10. Software change
• Software change is a common requirement
– 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.
10

11. 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 evolving existing software
rather than developing new software.
11

12. Spiral model of evolution
Specification Implem ention
Star t
Release 1
Operation Validation
Release 2
Release 3
12

13. 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.
13

14. Evolution processes
• 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.
14

15. Change identification and evolution
Change identification
process
New sy stem Change proposals
Software evolution
process
15

16. The system evolution process
Change Im pact Release Change Sy stem
requests anal y sis planning im plem enta tion release
Platform Sy stem
Fault repair
adaptation enhancem ent
16

17. Change implementation
Proposed Requirements Requir ements Software
changes analy sis upda ting de velopm ent
17

18. 18

19. 19

20. 20

21. 21

22. 22

23. 23

24. 24

25. WHAT ARE LEGACY SYSTEMS?
25

26. 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
26

27. 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)
27

28. 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.
28

29. 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.
29

30. Causal Dimensions of Legacy
Status
• System suitability
System – Suitability to organisation’s
Suitability mission
Underlying – Suitability to organisation
platform structure
– Suitability to process
• Underlying platform
Software
– Hardware, Operating system,
Quality
Networking, Development
environment and Data
management
• Software quality
– Component quality
– Design quality
– Change management quality30

31. Legacy Effects
– Asset value goes down – Ease of maintenance
• Mission criticality declines
• reliability • Cost of maintenance and
– Ease of operation goes down resistance to it
• User satisfaction • Availability of resources
• Ease of testing and auditing • Program size and
complexity
– Ease of migration / evolution
• Dependence on individuals
declines
• Ease of use of new technology
• Scalability
31

32. Finding a solution
• Slee and Slovin (1997) proposed a 4R portfolio matrix: -
Low business value Low business value
Low technology condition High technology condition
Retire Reassess
High business value High business value
Low technology condition High technology condition
Redevelop Renew
32

33. 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
33

34. 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
34

35. 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
35

36. 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
36

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

38. 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
38

39. 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
39

40. 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
40

41. 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
41

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

43. Architecture
• Component based
– Not necessarily object-oriented
– Good software component and design quality
• Object oriented
– Good software component and design quality
– Infrastructures may be too ‘leading edge’
• Layered architecture
– Promotes flexibility in adapting applications
– Requires sophisticated understanding of platforms
43

44. 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
44

45. 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 or scrap system, or maintain
• High-quality, High business value
– continue operation using normal maintenance practices
45

46. 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
46

47. 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.
47

48. 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
48

49. 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)
49

50. 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 50

51. 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?)
51

52. 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
52

53. 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.
53

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

55. 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.
55

56. 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.
56

57. The Capability Maturity Model
• What is the Capability Maturity Model (CMM)?
– The application of process management and quality
improvement concepts to software development and
maintenance.
– A guide for evolving toward a culture of engineering
excellence.
– A model for organizational improvement.
57

58. Capability Maturity Model
• Focuses on practices that are under control of the
software group
• Presents a minimum set of recommended practices that
have been shown to enhance a software development
and maintenance capability
– It defines the expectation (the “what”)
– Without overly constraining the implementation (the “how”)
58

59. Why We Chose CMM
• CMM today serves as a “seal of approval” in software
development
• CMM helped guide us towards standard, repeatable processes –
reduced learning time on how to get things done
• Standard practices mean time savings to our team - everyone
knows what to expect and what to deliver
• Our quality activities became more aligned within the project
rather than thought of as a separate event
• We rely on our processes and our people together, not just one or
the other
• Ideas in CMM creates an environment of improvement – if you
don’t like things one way, make it better!
59

60. Stages of Process Maturity
Level Focus Process Areas Quality
Continuous Organizational Innovation and Deployment
5 Optimizing Productivity
Process Causal Analysis and Resolution
Improvement
4 Quantitatively Quantitative Organizational Process Performance
Managed Management Quantitative Project Management
Requirements Development
Technical Solution
Product Integration
Verification
Validation
3 Defined Process Organizational Process Focus
Standardization Organizational Process Definition
Organizational Training
Integrated Project Mgmt (with IPPD extras)
Risk Management
Decision Analysis and Resolution
Integrated Teaming (IPPD only)
Org. Environment for Integration (IPPD only)
Integrated Supplier Management (SS only)
Requirements Management
Basic Project Planning
Project Monitoring and Control
2 Managed Project Supplier Agreement Management
Management Measurement and Analysis
Process and Product Quality Assurance
Configuration Management Risk
1 Initial Rework 60

61. Level 1: the “Initial” Level
Success depends on heroes
Good performance is possible - but
• Requirements often misunderstood, uncontrolled
• Schedules and budgets frequently missed
• Progress not measured
• Product content not tracked or controlled
• Engineering activities nonstandard, inconsistent
• Teams not coordinated, not trained
• Defects proliferate
61

62. CMMI Level 2: “Managed”
7 Process Areas
CLARIFY REQUIREMENTS
Baseline the product requirements – Requirements Management (REQM)
DOCUMENT PLANS
Estimate project parameters, Project Planning (PP)
Develop plans and processes
TRACK PROGRESS
Measure actual progress to enable – Project Monitoring
timely corrective action and Control (PMC)
Measure for mgmt. info needs – Measurement & Analysis (M&A)
Verify adherence of processes – Process & Product
and products to requirements Quality Assurance (PPQA)
CONTROL PRODUCTS
Identify and control products, – Configuration
changes, problem reports Management (CM)
Select qualified suppliers / vendors; – Supplier Agreement
manage their activities Management (SAM)
62

63. What Happens During Level 2
• Processes become easier to digest and understand
• Managers and team members spend less time
explaining how things are done and more time doing
• Projects are better estimated, better planned, and
more flexible
• Quality is integrated into the project
• Costs may go up initially, but do go down over time
• And yes, there may be more documentation and
paper
63

64. CMMI Level 3: “Defined”
11 Process Areas*
ENGINEER THE PRODUCT
• Clarify customer requirements
• Solve design requirements; develop – Requirements Definition (RD)
implementation processes – Technical Solution (TS)
• Assemble product components, deliver
• Ensure products meet requirements
• Ensure products fulfill intended use – Product Integration (PI)
• Analyze decisions systematically – Verification (Ver)
– Validation (Val)
• Follow integrated, defined processes – Decision Analysis
• Identify and control potential problems & Resolution (DAR)
MANAGE THE PROCESSES
• Establish org. responsibility for PI – Integrated Project Mgmt (IPM)
• Define the org’s best practices – Risk Management (RSKM)
• Develop skills and knowledge
PROVIDE ORG. INFRASTRUCTURE
– Org. Process Focus (OPF)
– Org. Process Definition (OPD)
– Org. Training (OT)
64

65. What Happens During Level 3
• Process Improvement becomes the standard – Cross-
Functional teams look for ways to “short-cut” the system
• Solutions go from being “coded” to being “engineered”
• Quality gates appear throughout the project effort with
the entire team involved in the process, reducing rework
• Risks are managed and don’t take the team by surprise
65

66. CMMI Level 4: “Quantitatively
Managed”
2 Process Areas
MANAGE PROJECTS QUANTITATIVELY
• Statistically manage the project’s – Quantitative Project Management
processes and sub-processes (QPM)
MANAGE THE ORGANIZATION
QUANTITATIVELY
• Understand process performance; – Organizational
quantitatively manage Process Performance (OPP)
the organization’s projects
66

67. CMMI Level 5: “Optimizing”
2 Process Areas
OPTIMIZE PERFORMANCE
• Identify and eliminate – Causal Analysis
the cause of defects early and Resolution (CAR)
ADOPT IMPROVEMENTS
• Identify and deploy new tools and process – Organizational Innovation
improvements to meet needs and business and Deployment (OID)
objectives
67

68. The CMM Maturity Levels
Maturity Level 1
Maturity Level 2
~
Maturity Level 3
~ ~ ~
Maturity Level 4
~ ~ ~ ~ ~ ~
Maturity Level 5
~ ~ ~ ~ ~ ~
68

69. Proving Maturity Levels
• Five characteristics must be demonstrated in each practice to be
assessed in that maturity level practice areas:
– Commitment to Perform – Policies, procedures, and resources to perform
the work
– Ability to Perform – Personnel, tools, and templates in place
– Activities Performed – Documentation and interviews demonstrating that
policies are implemented
– Measurement and Analysis – Metrics and other tools used to evaluate
effectiveness of processes
– Verifying Implementation – Independent review and evaluation of the
processes
• Maturity levels are proven through documentation (policies,
procedures, templates) and interviews of staff (to prove
institutionalization).
69

70. Implementation Best Practices
• Be Realistic – Some processes will be more ready
than others.
• Be Flexible – Allowing tailoring is key to adoption.
• Be Open – The key is to learn how to do things better,
not how to “comply”.
• Be Patient – It does not happen overnight.
70

71. Classifications of SDLC Model
SDLC Model
Sequential Progressive Iterative
V Model Waterfall
71

72. SW Process Models
• Waterfall model
• Evolutionary or Propgressive models
• Component-based development model
• Iterative Model
72

73. 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.
73

74. 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
74

75. Waterfall model diagram
75

76. 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.
76

77. Evolutionary Models
77

78. 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.
78

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

80. 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.
80

81. 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
81

82. The Prototyping Model
82

83. 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
83

84. 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.
84

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

86. 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
86

87. Iterative Models
87

88. 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.
88

89. 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
89

90. 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.
90

91. 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
91

92. 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
92

93. 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 93
Service test De velop , verify
ne xt-le vel pr oduct

94. 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.
94

95. 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)
95

96. 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.
96

97. 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
97