CSE403: Software Engineering
Lecture 23 (Software Evolution)
David Notkin

  1. Software evolution
    1. Software changes

                                                               i.      Software maintenance

                                                              ii.      Software evolution

                                                            iii.      Incremental development

    1. 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?

  1. A legacy
    1. 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”

    1. 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

  1. Change
    1. “There is in the worst of fortune the best of chances for a happy change” —Euripides
    2. He who cannot dance will say, “The drum is bad” —Ashanti proverb
    3. “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
    4. “Change in all things is sweet” —Aristotle
  2. Why does it change?
    1. Software changes does not change primarily because it doesn’t work right
    2. But rather because the technological, economic, and societal environment in which it is embedded changes
    3. 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

  1. Kinds of change
    1. Corrective maintenance (about 20% of maintenance costs)

                                                               i.      Fixing bugs in released code

    1. Adaptive maintenance (about 20% of maintenance costs)

                                                               i.      Porting to new hardware or software platform

    1. Perfective maintenance (about 60% of maintenance costs)

                                                               i.      Providing new functions

  1. Total life cycle cost
    1. Lientz and Swanson determined that at least 50% of the total life cycle cost is in maintenance
    2. There are several other studies that are reasonably consistent
    3. General belief is that maintenance costs somewhere between 50-75% of total life cycle costs
  2. Open question
    1. 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”?

    1. Measuring “reasonable” costs in terms of percentage of life cycle costs doesn’t make sense
  1. High-level answer
    1. 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

  1. Observations
    1. Maintainers often get less respect than developers
    2. Maintenance is generally assigned to the least experienced programmers
    3. Software structure degrades over time
    4. Documentation is often poor and is often inconsistent with the code

    5. Is there any relationship between these?
  2. Laws of Program Evolution
    1. 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

    1. P-type programs

                                                               i.      Well-defined, precisely specified

                                                              ii.      The challenge is efficient implementation

    1. E-type programs

                                                               i.      Ill-defined, fit into an ever-changing environment

                                                              ii.      The challenge is managing change

  1. Law of increasing complexity
    1. “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?

  1. Statistically regular growth
    1. “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

    1. Is this related to Brooks’ observation that adding people to a late project makes it later?
  1. And two others
    1. “The global activity rate in a large programming project is invariant.”
    2. “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”

  1. Approaches to reducing cost
    1. Design for change (proactive)

                                                               i.      Information hiding, layering, open implementation, aspect-oriented programming, etc.

    1. Tools to support change (reactive?)

                                                               i.      grep, etc.

                                                              ii.      Reverse engineering, program understanding, system summarization, …

    1. Improved documentation (proactive)

                                                               i.      Discipline, stylized approaches

    1. Reducing bugs (proactive)

                                                               i.      Many techniques, already covered

    1. Increasing correctness of specifications (proactive)
    2. Others?