Title: Software Evolution
1Chapter 21
2Objectives
- To explain why change is inevitable (if software
systems are to remain useful) - To discuss software maintenance and maintenance
cost factors
3Topics covered
- Program evolution dynamics (21.1)
- Software maintenance (21.2)
4Topics covered
- Program evolution dynamics (21.1)
- Software maintenance (21.2)
5Software 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.
6Software 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.
7Spiral model of evolution
8Program 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.
9Lehmans laws
1.
2.
3.
4.
(the saturated state idea)
5.
6.
7.
8.
(how to apply this?)
10Applicability 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?)
11Applicability 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.
12Topics covered
- Program evolution dynamics (21.1)
- Software maintenance (21.2)
13Software 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.
14Like 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)
15Maintenance 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.
16Types 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
17Types 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?
18Distribution of maintenance effort
19Maintenance 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.).
20Development/maintenance costs
reducing lifetime costs by spending more to
increase maintainability during development
21Maintenance cost factors
- So what factors affect maintenance costs?
22Maintenance 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.
23Maintenance 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.
24Maintenance 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.
25Maintenance 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?
26Maintenance 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?
27Change 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.)
28Change 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.
29Maintenance 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?
30Complexity 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.
31Process 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.
32Key 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.
33Chapter 21