Software Evolution - PowerPoint PPT Presentation

1 / 33
About This Presentation
Title:

Software Evolution

Description:

To explain why change is inevitable (if software systems are to remain useful) ... in 256K of memory, but which is now a giant requiring many megabytes of memory? ... – PowerPoint PPT presentation

Number of Views:38
Avg rating:3.0/5.0
Slides: 34
Provided by: CISE9
Category:

less

Transcript and Presenter's Notes

Title: Software Evolution


1
Chapter 21
  • Software Evolution

2
Objectives
  • To explain why change is inevitable (if software
    systems are to remain useful)
  • To discuss software maintenance and maintenance
    cost factors

3
Topics covered
  • Program evolution dynamics (21.1)
  • Software maintenance (21.2)

4
Topics covered
  • Program evolution dynamics (21.1)
  • Software maintenance (21.2)

5
Software change
  • Software change is inevitable
  • New requirements emerge when the software is
    used
  • The business environment changes
  • Errors must be repaired
  • New computers and equipment are added to the
    system
  • The performance or reliability of the system may
    have to be improved.

6
Software change (contd)
  • The ability to implement and manage change is
    critical since
  • Organizations have huge investments in their
    software systems - they are critical business
    assets.
  • To maintain the value of these assets, they must
    be changed and updated as necessary.
  • In fact, most of the software budget in large
    companies is devoted to evolving existing
    software rather than developing new software.

7
Spiral model of evolution
8
Program evolution dynamics
  • is the study of the processes of system change.
  • After major empirical studies, Lehman and Belady
    proposed a number of laws which apply to large
    systems as they evolved.
  • They are actually sensible observations rather
    than laws.

9
Lehmans laws
1.
2.
3.
4.
(the saturated state idea)
5.
6.
7.
8.
(how to apply this?)
10
Applicability of Lehmans laws
  • Lehmans laws seem to be generally applicable to
    large, custom systems developed by large
    organizations.
  • (But what about systems such as MS Word which
    originally operated in 256K of memory, but which
    is now a giant requiring many megabytes of
    memory?)

11
Applicability of Lehmans laws (contd)
  • Also, it is not clear how the laws should be
    modified for
  • Shrink-wrapped software products
  • Systems that incorporate a significant number of
    COTS components
  • Small organizations
  • Medium sized systems.

12
Topics covered
  • Program evolution dynamics (21.1)
  • Software maintenance (21.2)

13
Software maintenance
  • Modifying a program after it has been put into
    use to effect software change.
  • Does not normally involve major changes to the
    systems architecture.
  • Changes are implemented by modifying existing
    components and/or adding new components to the
    system.

14
Like software change, maintenance is inevitable
  • System requirements are likely to change while
    the system is being developed because the
    environment is changing.
  • (Therefore a newly delivered system may not meet
    its then current requirements!)
  • (contd)

15
Maintenance is inevitable (contd)
  • Also, when a system is installed in an
    environment, it changes that environment and
    therefore changes system requirements itself!
  • --------------------------------------------------
  • Systems MUST be maintained, therefore, if they
    are to remain useful.

16
Types of maintenance
  • Maintenance to repair software faults
  • Maintenance to adapt software to a different
    operating environment
  • Maintenance to add to or modify the systems
    functionality

17
Types of maintenance
  • Maintenance to repair software faults
  • Maintenance to adapt software to a different
    operating environment
  • Maintenance to add to or modify the systems
    functionality
  • How is maintenance effort typically divided
    between these three activities?

18
Distribution of maintenance effort
19
Maintenance costs
  • Usually greater than development costs (2 to 100
    times greater 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 very high support costs
    (e.g. old languages, compilers etc.).

20
Development/maintenance costs
reducing lifetime costs by spending more to
increase maintainability during development
21
Maintenance cost factors
  • So what factors affect maintenance costs?

22
Maintenance cost factors (contd)
  • 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.

23
Maintenance cost factors (contd)
  • 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.

24
Maintenance prediction
  • is concerned with assessing which parts of the
    system will be affected by change and what the
    costs of change will be.
  • This involves predicting
  • Maintainability of different system parts
  • Number of changes that will be required and the
    system parts that will be impacted and
  • Short- and long-term cost of maintenance.

25
Maintenance prediction (contd)
What parts of the system will be the most
expensive to maintain?
What parts of the system are most likely to be
affected by change requests?
26
Maintenance prediction (contd)
What parts of the system will be the most
expensive to maintain?
What parts of the system are most likely to be
affected by change requests?
27
Change prediction
  • Predicting the number of changes requires an
    understanding of the relationships between a
    system and its environment.
  • (Tightly coupled systems require changes
    whenever the environment is changed.)

28
Change prediction (contd)
  • Factors influencing this coupling are
  • Number and complexity of system interfaces
  • Number of inherently volatile system
    requirements and
  • The business processes associated with system use.

29
Maintenance prediction (contd)
What parts of the system will be the most
expensive to maintain?
What parts of the system are most likely to be
affected by change requests?
30
Complexity metrics
  • Studies have shown that most maintenance effort
    is spent on a relatively small number of system
    components.
  • Predictions of maintainability can be made by
    assessing the complexity of system components.
    E.g.,
  • Complexity of control structures
  • Complexity of data structures
  • Object, method (procedure) and module size.

(See, for example Identifying Error-Prone
Software - An Empirical Study (S.M. Thebaut, V.Y.
Shen, T.J. Yu, and L.R. Paulsen), IEEE
Transactions on SE 11(4) 317-324, 1985.
31
Process metrics
  • Process measurements taken over time may also 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 unresolved change requests.
  • If any or all of these is increasing, this may
    indicate a decline in maintainability.

32
Key points
  • Software development and evolution should be seen
    as a single, iterative process.
  • Lehmans Laws describe a number of insights
    into system evolution.
  • Three types of maintenance are bug fixing,
    adapting software for a new environment, and
    adding/modifying functionality.
  • For custom systems, maintenance costs usually far
    exceed development costs.

33
Chapter 21
  • Software Evolution
Write a Comment
User Comments (0)
About PowerShow.com