CSE403: Software Engineering
Lecture 23 (Software Evolution)
David Notkin
- Software
evolution
- Software
changes
i.
Software maintenance
ii.
Software evolution
iii.
Incremental development
- The
objective is to use an existing code base as an asset
i.
Cheaper and better to get there from here, rather than
starting from scratch
ii.
Anyway, where would you aim for with a new system?
- A
legacy
- Merriam-Webster
on-line dictionary
i.
“a gift by will especially of money or other personal
property”
ii.
“something transmitted by or received from an ancestor or predecessor
or from the past”
- The
usual joke is that in anything but software, you’d love to receive a
legacy
i.
Maybe we feel the same way about inheritance, too, especially
multiple inheritance
- Change
- “There
is in the worst of fortune the best of chances for a happy change”
—Euripides
- He
who cannot dance will say, “The drum is bad” —Ashanti proverb
- “The
ruling power within, when it is in its natural state, is so related to
outer circumstances that it easily changes to accord with what can be
done and what is given it to do” —Marcus Aurelius
- “Change
in all things is sweet” —Aristotle
- Why
does it change?
- Software
changes does not change primarily because it doesn’t work right
- But
rather because the technological, economic, and societal environment in
which it is embedded changes
- This
provides a feedback loop to the software
i.
The software is usually the most malleable link in the chain,
hence it tends to change
1.
Space shuttle astronauts have thousands of extra
responsibilities because it’s safer than changing code
- Kinds
of change
- Corrective
maintenance (about 20% of maintenance costs)
i.
Fixing bugs in released code
- Adaptive
maintenance (about 20% of maintenance costs)
i.
Porting to new hardware or software platform
- Perfective
maintenance (about 60% of maintenance costs)
i.
Providing new functions
- Total
life cycle cost
- Lientz
and Swanson determined that at least 50% of the total life cycle cost is
in maintenance
- There
are several other studies that are reasonably consistent
- General
belief is that maintenance costs somewhere between 50-75% of total life
cycle costs
- Open
question
- How
much maintenance cost is “reasonable?”
i.
Corrective maintenance costs are ostensibly not “reasonable”
ii.
How much adaptive maintenance cost is “reasonable”?
iii.
How much perfective maintenance cost is “reasonable”?
- Measuring
“reasonable” costs in terms of percentage of life cycle costs doesn’t
make sense
- High-level
answer
- For
perfective maintenance, it seems that the objective should be for the
cost of the change in the implementation to be proportional to the cost
of the change in the specification (design)
i.
Ex: Allowing dates for the year 2000 is (at most) a small
specification change
ii.
Ex: Adding call forwarding is a more complicated specification
change
- Observations
- Maintainers
often get less respect than developers
- Maintenance
is generally assigned to the least experienced programmers
- Software
structure degrades over time
- Documentation
is often poor and is often inconsistent with the code
- Is
there any relationship between these?
- Laws
of Program Evolution
- Law
of continuing change Belady & Lehman
i.
“A large program that is used undergoes continuing change or
becomes progressively less useful.”
ii.
Analogies to biological evolution have been made; the rate of
change in software is far faster
- P-type
programs
i.
Well-defined, precisely specified
ii.
The challenge is efficient implementation
- E-type
programs
i.
Ill-defined, fit into an ever-changing environment
ii.
The challenge is managing change
- Law
of increasing complexity
- “As
a large program is continuously changed, its complexity, which reflects
deteriorating structure, increases unless work is done to maintain or
reduce it.”
i.
Complexity, in part, is relative to a programmer’s knowledge
of a system
1.
Novices vs. experts doing maintenance
ii.
Cleaning up structure is done relatively infrequently
1.
Why?
- Statistically
regular growth
- “Measures
of [growth] are cyclically self-regulating with statistically
determinable trends and invariances.”
i.
(You can run but you can’t hide)
ii.
Based on data from OS/360 and some other systems
iii.
Ex: Content in releases decreases or time between releases
increases
- Is
this related to Brooks’ observation that adding people to a late project
makes it later?
- And
two others
- “The
global activity rate in a large programming project is invariant.”
- “For
reliable, planned evolution, a large program undergoing change must be
made available for regular user execution at maximum intervals determined
by its net growth.”
i.
This is related to Microsoft’s “daily builds”
- Approaches
to reducing cost
- Design
for change (proactive)
i.
Information hiding, layering, open implementation,
aspect-oriented programming, etc.
- Tools
to support change (reactive?)
i.
grep, etc.
ii.
Reverse engineering, program understanding, system
summarization, …
- Improved
documentation (proactive)
i.
Discipline, stylized approaches
- Reducing
bugs (proactive)
i.
Many techniques, already covered
- Increasing
correctness of specifications (proactive)
- Others?