Software Evolution

Michael L. Collard, Ph.D.

Department of Computer Science, The University of Akron

Development

  • Greenfield
  • Brownfield

Greenfield Development

  • Start with nothing and create a finished product, 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 C.S. 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 C.S. majors often end up doing

Maintenance

  • Changes to an existing system
  • Overwhelming part of the cost of the system over its lifetime (80%). However, typically not built into 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 can be seen as being maintenance activities.

IT Spending (1999) [Bohner,S]

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

Categories of Maintenance

  • 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

[Swanson,ISO/IEC 14764]

E.g., srcML New Features

  • Support for new languages, i.e., Java, C#, Objective-C
  • Support for custom DSLs (Domain Specific Languages)
  • Multi-language project support
  • Direct access to repositories (Subversion, git), and https:// sites

E.g., srcML Maintenance

  • Corrective
    • Parsing errors
  • Adaptive
    • Uses ANTLR 2.7.7, now have ANTLR 3 and 4, libxml, libarchive, take advantage of C++11
  • Perfective
    • Speed up translation. Redo design so that others (besides initial developer) can contribute with fixes, new languages, etc.
  • Preventive
    • Redo how preprocessor is handled, more parsing error checking
  • Note: Most of the srcML maintenance is necessary to implement new features

Software Evolution

  • Focus on supporting maintenance, not development for processes, tools, etc.
  • Does not distinguish between development and maintenance
  • Software Evolution = Software Development + Software 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 really observations
  • Limited data, however, 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
  • Development, installation, and operation of software changes the environment it is in
  • Assumptions are made during development, but changes in the environment invalidate these assumptions
  • Software evolution is part of a feedback-driven maintenance process. If 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)
  • As the software adapts to a changing environment, software gets more complex
  • Interactions between parts of the software increase in unstructured ways leads to an increase in entropy
  • Growth in complexity means it takes more time to add new features. Reducing complexity takes time away from adding 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 start to have the same characteristics (bugs, complexity, efficiency, etc.)
  • Over time, all projects will start to have the same characteristics
  • Development team is part of a larger organization. Interests and goals of the larger organization include more than this project
  • Feedback (resource allocation, pay, pats on back) from all levels of the larger organization work to keep the project inline
  • If the products of the organization have good characteristics, this is a good, if not, then 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 that managers make decisions that effect activity
  • Managers do control what is to be done, and the resources to do it. However, managers are constrained by union rules, skillset of personnel, etc. Also constrained by system characteristics, e.g., complexity
  • 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 software, more difficult it is for everybody to be familiar with all the goals
  • Larger the change, 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 same as Law I: Continuing Change, but isn’t
  • Scenario: Requirements are stated. Due to resources (budget, time, etc), not all requirements are implemented
  • Eventually, these 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 that has been performing satisfactorily for even a long period of time may suddenly exhibit unexpected, previously unobserved behavior
  • Gap between software and the real-world operational domain. Real world is always changing
  • This uncertainty about software increases with time unless actions are taken during maintenance
  • Familiarity breeds contempt, user satisfaction will change 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 I

  • Software must change over time
  • Changes cause complexity. Complexity increases cost of change. Resources allocated to simplify software take away from features
  • Software projects in an organization tend towards the same quality, bug rate, etc.

Lehman’s Laws Summary II

  • Over time, 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 important
  • Without changes, software appears to decrease in quality
  • What effects software evolution is a multi-level, multi-iteration process