Software%20Evolution

1
Software Evolution

• Managing the processes of software system change
• Objectives
• To explain different strategies for changing
  software systems
• Software maintenance
• Architectural evolution
• Software re-engineering
• To explain the principles of software maintenance

2
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

3
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

4
Lehmans laws
5
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

6
Types of maintenance

• Corrective
• Maintenance to repair software faults
• Adaptive
• Maintenance to adapt software to a different
  operating environment
• Perfective
• Maintenance to add to or modify the systems
  functionality

7
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

8
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

9
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

10
Distribution factors
11
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

12
Layered distribution model
13
Legacy system distribution
14
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

15
Distribution option spectrum
16
Software re-engineering

• 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

17
Re-engineering 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

18
Forward engineering and re-engineering
19
Re-engineering approaches
20
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

21
Program restructuring Spaghetti logic
22
Program restructuring Structured control logic
23
Program restructuring Condition simplification
-- Complex condition if not (A gt B and (C lt D or
not ( E gt F) ) )... -- Simplified condition if
(A lt B and (Cgt D or E gt F)...
24
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

25
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

26
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

27
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
  systems replacement
• The design and specification may be reverse
  engineered to support program maintenance

28
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 adaptive, perfective, and
  corrective

29
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