Legacy Systems and Software Change Sommerville Chapters 26, 27

1
Legacy Systems and Software Change Sommerville
- Chapters 26, 27

• Lecture to cover following-
• Legacy System Structures
• Legacy System Assessment
• Software Maintenance
• Architectural Evolution

2
Legacy Systems

• Older software systems that remain vital to an
  organisation
• Issues
• Legacy system structures
• Legacy system design
• Legacy system assessment

3
Legacy Systems

• Software systems that are developed specially for
  an organisation have a long lifetime
• Many software systems that are still in use were
  developed many years ago using technologies that
  are now obsolete
• These systems are still business critical that
  is, they are essential for the normal functioning
  of the business
• They have been given the name legacy systems

4
Legacy System Replacement

• There is a significant business risk in simply
  scrapping a legacy system and replacing it with a
  system that has been developed using modern
  technology
• Legacy systems rarely have complete
  specification. During their lifetime they have
  undergone major changes which may not have been
  documented
• Business processes are reliant on the legacy
  system
• The system may embed business rules that are not
  formally documented elsewhere
• New software development is risky and may not be
  successful

5
Legacy System Change

• Systems must change to remain useful
• Changing legacy systems is often expensive
• Different parts implemented by different teams so
  no consistent programming style
• System may use obsolete programming language
• The system documentation is often out-of-date
• The system structure may be corrupted by many
  years of maintenance
• Techniques to save space or increase speed at
  expense of understandability may have been used
• File structures used may be incompatible

6
The Legacy Dilemma

• It is expensive and risky to replace the legacy
  system
• It is expensive to maintain the legacy system
• Businesses must weigh up the costs and risks and
  may choose to extend the system lifetime using
  techniques such as re-engineering.

7
Legacy System Structures

• Legacy systems can be considered socio-technical
  systems, not simply software systems
• System hardware - may be mainframe hardware
• Support software - operating systems/utilities
• Application software - several different programs
• Application data - data used by these programs
  that is often critical business information
• Business processes - the processes that support a
  business objective and which rely on the legacy
  software and hardware
• Business policies and rules - constraints on
  business operations

8
Layered Model
9
System Change

• Should be possible to replace a layer in system
  leaving other layers unchanged
• In practice, this is usually impossible
• Changing one layer introduces new facilities and
  higher level layers must then change to make use
  of these
• Changing the software may slow it down so
  hardware changes are then required
• It is often impossible to maintain hardware
  interfaces because of the wide gap between
  mainframes and client-server systems

10
Legacy System Design

• Most legacy systems were designed before
  object-oriented development was used
• Rather than being organised as a set of
  interacting objects, these systems have been
  designed using a function-oriented design
  strategy
• Several methods and CASE tools are available to
  support function-oriented design and the approach
  is still used for many business applications

11
Functional Design Process

• Data-flow design
• Model the data processing in the system using
  data-flow diagrams
• Structural decomposition
• Model how functions are decomposed to
  sub-functions using graphical structure charts
  that reflect the input/process/output structure
• Detailed design
• The functions in the design and their interfaces
  are described in detail.

12
Using Function-oriented Design

• For some classes of system, such as some
  transaction processing systems, a
  function-oriented approach may be a better
  approach to design than an object-oriented
  approach
• Companies may have invested in CASE tools and
  methods for function-oriented design and may not
  wish to incur the costs and risks of moving to an
  object-oriented approach

13
Legacy System Assessment

• 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

14
System Quality and Business Value
15
Legacy System Categories

• 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

16
Business Value 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

17
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 systems environment and how
  expensive is it to maintain
• Application assessment
• What is the quality of the application software
  system

18
Business Process Assessment

• Use a viewpoint-oriented approach and seek
  answers from system stakeholders
• Is there a defined process model and is it
  followed?
• Do different parts of the organisation use
  different processes for the same function?
• How has the process been adapted?
• What are the relationships with other business
  processes and are these necessary?
• Is the process effectively supported by the
  legacy application software?

19
Environment Assessment
20
Application Assessment
21
System Measurement

• You may collect quantitative data to make an
  assessment of the quality of the application
  system
• The number of system change requests
• The number of different user interfaces used by
  the system
• The volume of data used by the system

22
Software Change

• Managing the processes of software system change
• Issues
• Program evolution dynamics
• Software maintenance
• Architectural evolution

23
Software Change

• Software change is inevitable
• New requirements emerge when the software is used
• The business environment changes
• Errors must be repaired
• New equipment must be accommodated
• The performance or reliability may have to be
  improved
• A key problem for organisations is implementing
  and managing change to their legacy systems

24
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 but it is
  restructured and reorganised to facilitate future
  changes
• These strategies may be applied separately or
  together

25
Program Evolution Dynamics

• Program evolution dynamics is the study of the
  processes of system change
• After major empirical study, 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

26
Lehmans Laws
27
Applicability of Lehmans Laws

• This has not yet been established
• They are generally applicable to large, tailored
  systems developed by large organisations
• It is not clear how should be modified for
• Shrink-wrapped software products
• Systems that incorporate a significant number of
  COTS components
• Small organisations
• Medium sized systems

28
Software Maintenance

• Modifying a program after it has been put into
  use
• Maintenance does not normally involve major
  changes to the systems architecture
• Changes are implemented by modifying existing
  components and adding new components to the system

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

30
Types of Maintenance

• 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 systems
  functionality
• Modifying the system to satisfy new requirements

31
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 so makes further
  maintenance more difficult.
• Ageing software can have high support costs
  (e.g. old languages, compilers etc.)

32
Development/maintenance Costs
33
Maintenance Cost Factors

• Team stability
• Maintenance costs are reduced if the same staff
  are involved with them for some time
• Contractual responsibility
• Developers may have no contractual responsibility
  for maintenance so no incentive to design for
  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

34
Evolutionary Software

• Rather than think of separate development and
  maintenance phases, evolutionary software is
  software that is designed so that it can
  continuously evolve throughout its lifetime

35
The Maintenance Process
36
Change Requests

• Change requests are requests for system changes
  from users, customers or management
• In principle, all change requests should be
  carefully analysed as part of the maintenance
  process and then implemented
• In practice, some change requests must be
  implemented urgently
• Fault repair
• Changes to the systems environment
• Urgently required business changes

37
Change Implementation
38
Emergency Repair
39
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

40
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 system is used

41
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
• Procedure and module size

42
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

43
Architectural Evolution

• There is a need to convert many legacy systems
  from a centralised architecture to a
  client-server architecture
• Change drivers
• Hardware costs. Servers 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

44
Distribution Factors
45
Legacy System Structure

• Ideally, for distribution, there should be a
  clear separation between the user interface, the
  system services and the system data management
• In practice, these are usually intermingled in
  older legacy systems

46
Legacy System Structures
47
Layered Distribution Model
48
Legacy System Distribution
49
Distribution Options

• The more that is distributed from the server to
  the client, the higher the costs of architectural
  evolution
• The simplest distribution model is UI
  distribution where only the user interface is
  implemented on the server
• The most complex option is where the server
  simply provides data management and application
  services are implemented on the client

50
Distribution Option Spectrum
51
Key Points

• A legacy system is an old system that still
  provides essential business services
• Legacy systems are not just application software
  but also include business processes, support
  software and hardware
• Most legacy systems are made up of several
  different programs and shared data
• A function-oriented approach has been used in the
  design of most legacy systems

52
Key Points

• The structure of legacy business systems normally
  follows an input-process-output model
• The business value of a system and its quality
  should be used to choose an evolution strategy
• The business value reflects the systems
  effectiveness in supporting business goals
• System quality depends on business processes, the
  systems environment and the application software

53
Key Points

• Software change strategies include software
  maintenance, architectural evolution and software
  re-engineering
• Lehmans Laws are invariant relationships that
  affect the evolution of a software system
• Maintenance types are
• Maintenance for repair
• Maintenance for a new operating environment
• Maintenance to implement new requirements

54
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
• A distributed user interface can be supported
  using screen management middleware