Software Evolution

Michael L. Collard, Ph.D.

Department of Computer Science, The University of Akron

Greenfield Development

Start with nothing and create a finished product with no existing code, design, or previous system.

  • Most SE books, education, processes, tools, etc. stress greenfield development
  • However, there is little pure greenfield development in the real world
  • What Computer Science majors see themselves as doing

Brownfield Development

Start with an existing project/environment and create a finished product with existing code, design, or previous system

  • Most SE books, education, processes, tools, etc., treat brownfield development as a side topic
  • However, most development in the real world is brownfield development
  • What Computer Science majors often end up doing


Changes to an existing system

  • Overwhelming part of the cost of the system over its lifetime (80%). However, typically not built into the cost structure
  • Bad terminology. Maintenance of software is not the same as maintenance in other fields
  • Most SE books, education, processes, tools, etc., treat maintenance as a side topic. However, much of what software developers do are maintenance activities.

IT Spending (1999) [Bohner,S]

Relative Costs of Phases of a Life-cycle [Schach 1999]

Categories of Maintenance [Swanson, ISO/IEC 14764]

  • Corrective
    • Fix bugs/problems
  • Adaptive
    • Change to fit new environment (API, compiler)
  • Perfective
    • Improve performance or maintainability
  • Preventive
    • Detect and correct latent problems before they become actual problems

Software Evolution

Software Evolution = Software Development + Software Maintenance

  • Focus on supporting maintenance, not development for processes, tools, etc.
  • Does not distinguish between development and maintenance
  • Example: open-source model


Lehman's Laws of Software Evolution

  • Originally based on observations of a few commercially-developed systems
  • 3 to 8 "laws", but are observations.
  • Limited data, however, is an important start.
  • Individual laws are not important, only the overall conclusions.
  • Interesting tie-in to disruptive innovation and why companies have difficulty changing.

Law I: Continuing Change

A program that is used must be continually adapted; else, it becomes progressively less satisfactory

  • Software has to be frequently updated.
  • Why? Development, installation, and operation of software change the environment.
  • Why? Assumptions are made during development but are invalidated by changes in the environment.
  • If software evolution is not allowed to occur, satisfaction with the software declines.

Law II: Increasing Complexity

As a program is evolved, its complexity increases unless work is done to maintain or reduce it

  • Similar to the Second Law of Thermodynamics (entropy)
  • Changing environment leads to more complexity
  • Why? Unstructured interactions between parts of the software -> increase in entropy
  • Why? Growth in complexity -> more time to add a new feature. Reducing complexity -> less time for new features
  • Need a balance of adding new features and reducing complexity

Law III: Self Regulation

The program evolution process is self-regulating with close to normal distribution of measures of product and process attributes

  • Over time, all iterations will have the same characteristics (bugs, complexity, efficiency, etc.).
  • Over time, all projects will have the same characteristics.
  • Why? The development team is part of a larger organization whose interests and goals include more than this project.
  • Why? Feedback (resource allocation, pay) from all levels of the larger organization work to keep the project in line.
  • If the organization's products have good characteristics, this is good; if not, this is bad.

Law IV: Conservation of Organisational Stability

The average effective global activity rate on an evolving system is invariant over the product life time

  • Rate of development (features, tasks, etc.) doesn't change much over the long-term life of the product.
  • Counter-intuitive. People (especially managers) believe managers make decisions that affect the activity.
  • Why? Managers do control resources and may control what we do. However, union rules, the skillset of personnel, etc., constrain management. System characteristics, e.g., complexity, also constrain them.
  • Providing additional resources may reduce overall effectiveness [Brooks].

Law V: Conservation of Familiarity

During the active life of an evolving program, the content of successive releases is statistically invariant

  • Good progress is made when everyone is familiar with the goals
  • The more changes/additions to the software, the more difficult it is for everybody to be familiar with all the goals
  • Larger the change, the less likely everybody is familiar with it
  • Trigger points at which this occurs

Law VI: Continuing Growth

Functional content of a program must be continually increased to maintain user satisfaction over its lifetime

  • Appears the same as Law I: Continuing Change, but isn't
  • Scenario: Customer states the requirements, but due to resources (budget, time, etc.), we don't implement all the requirements.
  • Eventually, unimplemented requirements may be requested by users.

Law VII: Declining Quality

… programs will be perceived as of declining quality unless rigorously maintained and adapted to a changing operational environment

  • Software performing satisfactorily for a long time may suddenly exhibit unexpected behavior.
  • Why? The gap between software and the real-world operational domain. The real world is constantly changing.
  • Why? This uncertainty about software increases with time unless we take action during maintenance.
  • User satisfaction changes over time.

Law VIII: Feedback System

Programming Processes constitute Multi-loop, Multi-level Feedback systems and must be treated as such to be successfully modified or improved

  • All other parts of this set of laws include feedback.
  • Multi-loop: various iterations
  • Multi-level: users, development team, testing, management, critics

Lehman's Laws Summary

Law I: Continuing Change
Law II: Increasing Complexity
Law III: Self Regulation
Law IV: Conservation of Organisational Stability
Law V: Conservation of Familiarity
Law VI: Continuing Growth
Law VII: Declining Quality
Law VIII: Feedback System

  • Software must change over time.
  • Changes cause complexity. Complexity increases the cost of change—resources allocated to reduce complexity take away from features.
  • Software projects in an organization tend towards the same quality, bug rate, etc.
  • Over time, the rate of development for each iteration doesn't vary much. Tend to meet the same number of goals with each iteration.
  • Must implement features that were previously not considered necessary.
  • Without changes, the software appears to decrease in quality.
  • What affects software evolution is a multi-level, multi-iteration process.