Lecture 9 - Software Evolution
Lecture 9 - Software Evolution
Part 1
Evolution processes
Change processes for software systems
Program evolution dynamics
Understanding software evolution
Software maintenance
Making changes to operational software systems
Legacy system management
Making decisions about software change
Evolution
The stage in a software system’s life cycle where it is in
operational use and is evolving as new requirements are
proposed and implemented in the system.
Servicing
At this stage, the software remains useful but the only changes
made are those required to keep it operational i.e. bug fixes and
changes to reflect changes in the software’s environment. No
new functionality is added.
Phase-out
The software may still be used but no further changes are made
to it.
Law Description
Continuing change A program that is used in a real-world environment must necessarily
change, or else become progressively less useful in that
environment.
Law Description
Declining quality The quality of systems will decline unless they are
modified to reflect changes in their operational
environment.
Feedback system Evolution processes incorporate multiagent, multiloop
feedback systems and you have to treat them as
feedback systems to achieve significant product
improvement.
Lecture 9 Software evolution 20
Applicability of Lehman’s laws
Part 2
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.
Lecture 9 Software evolution 29
Maintenance prediction
Duplicate code
The same or very similar code may be included at different
places in a program. This can be removed and implemented as
a single method or function that is called as required.
Long methods
If a method is too long, it should be redesigned as a number of
shorter methods.
Switch (case) statements
These often involve duplication, where the switch depends on
the type of a value. The switch statements may be scattered
around a program. In object-oriented languages, you can often
use polymorphism to achieve the same thing.
Data clumping
Data clumps occur when the same group of data items (fields in
classes, parameters in methods) re-occur in several places in a
program. These can often be replaced with an object that
encapsulates all of the data.
Speculative generality
This occurs when developers include generality in a program in
case it is required in the future. This can often simply be
removed.
Factor Questions
Supplier stability Is the supplier still in existence? Is the supplier financially stable and
likely to continue in existence? If the supplier is no longer in
business, does someone else maintain the systems?
Failure rate Does the hardware have a high rate of reported failures? Does the
support software crash and force system restarts?
Age How old is the hardware and software? The older the hardware and
support software, the more obsolete it will be. It may still function
correctly but there could be significant economic and business
benefits to moving to a more modern system.
Factor Questions
Support requirements What local support is required by the hardware and
software? If there are high costs associated with this
support, it may be worth considering system replacement.
Maintenance costs What are the costs of hardware maintenance and support
software licenses? Older hardware may have higher
maintenance costs than modern systems. Support software
may have high annual licensing costs.
Factor Questions
Understandability How difficult is it to understand the source code of the current
system? How complex are the control structures that are used?
Do variables have meaningful names that reflect their function?
Data Is there an explicit data model for the system? To what extent is
data duplicated across files? Is the data used by the system up to
date and consistent?
Factor Questions
Programming language Are modern compilers available for the programming
language used to develop the system? Is the programming
language still used for new system development?
Configuration Are all versions of all parts of the system managed by a
management configuration management system? Is there an explicit
description of the versions of components that are used in
the current system?
Test data Does test data for the system exist? Is there a record of
regression tests carried out when new features have been
added to the system?
Personnel skills Are there people available who have the skills to maintain
the application? Are there people available who have
experience with the system?