CS 425/625 Software Engineering Software Evolution

1
CS 425/625 Software Engineering Software
Evolution

• Based on Chapter 21 of the textbook SE-8 Ian
  Sommerville,
• Software Engineering, 8th Ed., Addison-Wesley,
  2006 and on the
• Ch21 PowerPoint presentation available at the
  books web-site
• November 14, 2007

2
Outline

• Introduction
• Program Evolution Dynamics
• Software Maintenance
• Overview
• Prediction
• Evolution Processes
• Legacy Systems

3
Introduction
.

• Software evolves continuously due to demands for
  changes
• New requirements surface
• Existing requirements need be modified
• Errors found need be fixed
• In some cases 90 of software costs are evolution
  costs
• When the transition from development to evolution
  is not smooth, changing software after delivery
  is called software maintenance

4
.Introduction

• A spiral model of development and evolution Fig.
  21.1, SE-8

5
Program evolution dynamics

6
Software Maintenance Overview.

• Software maintenance the activities of changing
  the system after it has been delivered
• Types of software maintenance
• Corrective maintenance repair of software faults
  
• Adaptive maintenance modification of software
  due to changes in the operating environment
  (hardware, supporting software)
• Perfective maintenance additions to and/or
  modifications of system functionality due to
  organizational or business changes

7
Software Maintenance .Overview...

• Distribution of maintenance effort Fig. 21.3,
  SE-8

8
Software Maintenance ..Overview..

• Software maintenance is a natural continuation of
  the development process (specification, design,
  implementation, testing). Hence the term
  evolution (applied especially when the transition
  from development is seamless)
• Development and maintenance costs vary from
  application to application
• Investing in development leads to reduction of
  both maintenance costs and overall project costs
  slide 9

9
Software Maintenance Overview.

• Costs of development and maintenance Fig. 21.4,
  SE-8

10
Software Maintenance .Overview

• Why maintenance costs are higher than development
  costs? Factors
• Team stability development teams break up after
  delivery
• Contractual responsibility different teams or
  organizations have the responsibility for
  maintenance
• Staff skills more experienced software engineers
  tend to avoid maintenance
• Program age and structure not structured in the
  first place, the program copes poorly with
  changes and its structure degrades

11
Software Maintenance Prediction.

• Maintenance prediction Fig. 21.5, SE-7

12
Software Maintenance .Prediction

• Generally, more complex the software, more
  expensive its maintenance
• The relationship between a system and its
  environment is also important. This relationship
  is characterized by
• Number and complexity of interfaces
• Number of inherently volatile requirements
• The business process in which the system is used
• Factors used to assess maintainability
• Number of requests for corrective maintenance
• Average time required for impact analysis
• Average time taken to implement a change
• Number of outstanding change requests

13
Evolution Processes..

• The evolution process overview Fig. 21.7, SE-8

14
.Evolution Processes.

• Change implementation Fig. 21.8, SE-8

15
..Evolution Processes

• Emergency repair Fig. 21.9, SE-8. Prompted by
• System faults
• Business changes
• Environmental changes
• all requiring urgent treatment.
• The dangers of emergency repair
• Software becomes inconsistent
• Changes are not reflected in documentation
• Software ageing is accelerated by workaround
  solutions

16
Legacy Systems Introduction..

• Legacy systems old computer-based systems still
  in use by organizations
• Many of them still business critical
• Incorporate many changes made over the years
• Many people have been involved in these changes
• Replacing legacy systems with new systems is
  risky, yet keeping them means new changes become
  more and more expensive

17
Legacy Systems .Introduction.

• Risks of replacing a legacy system
• Specification is difficult because existing
  documentation is typically incomplete
• Changing business processes (now adjusted to the
  system) may entail high costs
• Undocumented, yet important business rules may be
  embedded in the system a new system may break
  these rules
• The new system may be delivered late, may cost
  more than expected, and may not function properly

18
Legacy Systems ..Introduction

• Factors that make changes to legacy systems
  expensive
• In large systems, different parts were
  implemented by different teams, without
  consistent programming style
• It is difficult to find personnel who knows the
  obsolete programming languages used in old
  systems
• In may cases the only documentation is provided
  by the source code even this may be missing
• It is difficult to understand the system given
  its ad hoc updating over the years
• Data used by the system is difficult to
  understand and manipulate it can also be
  obsolete and/or redundant

19
Legacy system assessment..

• Strategic approaches for dealing with legacy
  systems
• Scrap the system completely
• When business practices have changed and no
  longer depend significantly on the system (they
  may be supported by new COTS)
• Continue to maintain the system
• The system works well, is fairly stable, and
  users do not request many changes
• Transform the system to improve maintainability
• When system quality was affected negatively by
  changes, yet changes are still required
• Replace the system with a new one
• When obsolete hardware precludes further
  operation or the new system can be built at
  reasonable cost

20
.Legacy system assessment.

• Assessing legacy systems example Fig. 21.13 SE-8

21
..Legacy system assessment

• Assessment of legacy systems includes
• Business value assessment (subjective).
  Viewpoints
• End-users look at systems functionality and
  performance
• Customers look at the quality of services
  provided
• Business managers assess the usefulness of the
  system in terms of business support
• IT managers are concerned with the availability
  of technical support for the system
• Senior managers interested in systems
  contribution to the business goals
• System quality assessment (next)

22
Legacy system assessment..

• System quality assessment. Look at all components
  of the system. Hence
• Business process assessment. Possible questions
• Are defined process models and procedures in
  place?
• Are processes applied consistently across the
  company?
• What adaptations have been made?
• Are relationships with other business processes
  necessary?
• Are processes suitably supported by application
  software?
• Environment assessment support software
  hardware platform (maintenance costs, faults,
  etc. slide 23)
• Application software assessment. Factors
  considered as in slide 24 and quantitative data
  such as
• Number of system change requests
• Number of different user interfaces
• Volume of data used by the system

23
.Legacy system assessment.

• Factors in environment assessment Fig. 21.14
  SE-8

24
..Legacy system assessment

• Factors in application software assessment Fig.
  21.15 SE-8