Module SEO01 Software Evolution - PowerPoint PPT Presentation

1 / 46
About This Presentation

Module SEO01 Software Evolution


Time pressure misleads designers into thinking that they have no time for proper ... 'An emerging theory of software process and software evolution', i.e., work ... – PowerPoint PPT presentation

Number of Views:59
Avg rating:3.0/5.0
Slides: 47
Provided by: etfube


Transcript and Presenter's Notes

Title: Module SEO01 Software Evolution

Module SE-O-01 Software Evolution
Topic 3 Software Aging
  • Software Aging by D. L. Parnas
  • Lehmans Laws of Software Evolution

Software Aging
  • Programs, like people, get old. We cant prevent
    aging, but we can understand its causes, take
    steps to limit its effects, temporarily reverse
    some of the damage it has caused, and prepare for
    the day when the software is no longer viable.
    ... (We must) lose our preoccupation with the
    first release and focus on the long term health
    of our products.
  • D.L. Parnas

Software Aging?
  • It does not make sense to talk about software
  • Software is a mathematical product, mathematics
    does not decay with time.
  • If a theorem was correct 200 years ago, it will
    be correct tomorrow.
  • If a program is correct today, it will be correct
    100 years from now.
  • If a program is wrong 100 years from now, it must
    have been wrong when it was written.
  • All of the above statements are true, but not
    really relevant.

Software Does Age
  • Software aging is gaining in significance
  • of the growing economic importance of software,
  • software is the capital of many high-tech firms.

Software Does Age
  • The authors and owners of new software products
    often look at aging software with disdain.
  • If only the software had been designed using
    todays languages and techniques
  • Like a young jogger scoffing at an 86 year old
    man (ex-champion swimmer) and saying that he
    should have exercised more in his youth!

The Causes of Software Aging
  • There are two types of software aging
  • Lack of Movement Aging caused by the failure of
    the products owners to modify it to meet
    changing needs.
  • Ignorant Surgery Aging caused as a result of
    changes that are made.
  • This one-two punch can lead to rapid decline in
    the value of a software product.

Lack of Movement
  • Unless software is frequently updated, its users
    will become dissatisfied and change to a new
  • Excellent software developed in the 60s would
    work perfectly well today, but nobody would use
  • That software has aged even though nobody has
    touched it.
  • Actually, it has aged because nobody bothered to
    touch it.

Ignorant Surgery
  • One must upgrade software to prevent aging.
  • Changing software can cause aging too.
  • Changes are made by people who do not understand
    the software.
  • Hence, software structure degrades.

Ignorant Surgery (Contd)
  • After many such changes nobody understands the
  • the original designers no longer understand the
    modified software,
  • those who made the modification still do not
    understand the software.
  • Changes take longer and introduce new bugs.
  • Inconsistent and inaccurate documentation makes
    changing the software harder to do.

The Cost of Software Failure
  • Inability to keep up,
  • reduced performance,
  • decreasing reliability.

Inability To Keep Up
  • As software ages, it grows bigger.
  • Weight gain is a result of the fact that the
    easiest way to add a feature is to add new code.
  • Changes become more difficult as the size of the
    software increases because
  • There is more code to change,
  • it is more difficult to find the routines that
    must be changed.
  • Result Customers switch to a younger product
    to get the new features.

Reduced Performance
  • As the size of the program grows, it places more
    demands on the computer memory.
  • Customers must upgrade their computers to get
    acceptable response.
  • Performance decreases because of poor design that
    has resulted from long-term ad-hoc maintenance.
  • A younger product will run faster and use less
    memory because it was designed to support the new

Decreasing Reliability
  • As the software is maintained, errors are
  • Many studies have shown that each time an attempt
    is made to decrease the failure rate of a system,
    the failure rate got worse!
  • That means that, on average, more than one error
    is introduced for every repaired error.

Decreasing Reliability (Contd)
  • Often the choice is to either
  • abandon the project
  • stop fixing bugs
  • For a commercial product, Parnas was once told
    that the list of known unrepaired bugs exceeded

Reducing the Cost of SW Aging
  • We should be looking far beyond the first release
    to the time when the product is old.
  • Inexperienced programmers get a rush after the
    first successful compile or demonstration.
  • Experienced programmers realize that this is only
    the beginning ...

Reducing the Cost of SW Aging (Contd)
  • Responsible, professional, organizations realize
    that more work is invested between the time after
    the first successful run and the first release
    than is required to get the first successful run.
  • Extensive testing and rigorous reviews are

Preventive Medicine
  • Design for success
  • Keep records (documentation)
  • Seek second opinions (reviews)

Design for Success
  • Design for change.
  • This principle is known by various names
  • information hiding
  • abstraction
  • separation of concerns
  • data hiding
  • object-orientation

Design for Change
  • To apply this principle one begins by trying to
    characterize the changes that are likely to occur
    over the lifetime of a product.
  • Since actual changes cannot be predicted,
    predictions will be about classes of changes
  • changes in the UI
  • change to a new windowing system
  • changes to data representation
  • porting to a new operating system ...

Design for Change (Contd)
  • Since it is impossible to make everything equally
    easy to change, it is important to
  • estimate the probabilities of each type of change
  • organize the software so that the items that are
    most likely to change are confined to a small
    amount of code

Why is Design for Change Ignored?
  • Textbooks fail to discuss the process of
    estimating the probability of change for various
    classes of changes.
  • Programmers are impatient because they are too
    eager to get the first version working.
  • Designs that result from this principle are
    different from the natural designs of the
    programmers intuition.

Why is Design for Change Ignored? (Contd)
  • Few good examples of the application of the
    principle. Designers tend to mimic other designs
    they have seen.
  • Programmers tend to confuse design principles
    with languages.
  • Many practitioners lack training in software

Keeping Records (Documentation)
  • Even when software is well designed, it is often
    not documented.
  • When documentation is present it is often
  • poorly organized
  • inconsistent
  • incomplete
  • written by people who do not understand the system

  • Hence, documentation is ignored by maintainers.
  • Worse, documentation is ignored by managers
    because it does not speed up the initial release.

Second Opinions (Reviews)
  • In engineering, as in medicine, the need for
    reviews by other professionals is never
  • In designing a building, ship, aircraft, there is
    always a series of design documents that are
    carefully reviewed by others.

  • This is not true in the software industry
  • Many programmers have no professional training in
    software at all.
  • Emphasis of CS degrees on mathematics and
    science professional discipline is not a topic
    for a liberal education.
  • Difficult to find people who can serve as quality
    reviewers no money to hire outsiders.
  • Time pressure misleads designers into thinking
    that they have no time for proper reviews.
  • Many programmers resent the idea of being

  • Every design should be reviewed and approved by
    someone whose responsibilities are for the
    long-term future of the product.

Why is Software Aging Inevitable?
  • Our ability to design for change depends on our
    ability to predict the future.
  • We can do so only approximately and imperfectly.
  • Over a period of years
  • changes that violate original assumptions will be
  • documentation will never be perfect
  • reviewers are bound to miss flaws ...

Why is Software Aging Inevitable? (Contd)
  • Preventive measures are worthwhile but anyone who
    thinks that this will eliminate aging is living
    in a dream world.

Software Geriatrics
  • Retroactive Documentation
  • A major step in slowing the age of older
    software, and often rejuvenating it, is to
    upgrade the quality of the documentation.
  • Retroactive Modularization
  • Change structure so that each module hides a
    design decision that is likely to change.

Software Geriatrics (Contd)
  • Amputation
  • A section of code has been modified so often, and
    so thoughtlessly, that it is not worth saving.
  • Major Surgery (Restructuring)
  • Identify and eliminate redundant components and
    gratuitous dependencies.

Planning Ahead
  • Its time to stop acting as if getting it to
    run was the only thing that matters.
  • Designs and changes have to be documented and
    carefully reviewed.
  • If its not documented, its not done.
  • In other areas of engineering, product
    obsolescence is recognized and included in design
    and marketing plans.
  • The same should be done for software engineering.

  • Software Aging by D. L. Parnas
  • Lehmans Laws of Software Evolution

Lehmans Laws of Evolution
  • Program evolution dynamics is the study of the
    processes of software system change
  • After major empirical studies, Lehman and Belady
    proposed a number of "laws" that seem to be
    applicable to all evolving software systems

Lehmans Laws of Evolution
  • Lehman's laws of software evolution
  • Based on the evolution of IBM 360 mainframe OS
    over a period of 30 years
  • M. M. Lehman, L. Belady. Program Evolution
    Processes of Software Change. Academic Press,
    London, 1985, 538pp.
  • M. M. Lehman. Laws of Software Evolution
    Revisited. Lecture Notes in Computer Science
    1149, pp. 108-124, Springer Verlag, 1997
  • Laws Reflect the cooperative activity of many
    individuals and organisational behaviour
  • Influenced by thermodynamics
  • Reflect established observations and empirical
  • An emerging theory of software process and
    software evolution, i.e., work in progress

Lehmans Laws of Evolution
  • Law 1 Continuing change
  • Law 2 Increasing complexity
  • Law 3 Self regulation
  • Law 4 Conservation of organisational stability
  • Law 5 Conservation of familiarity
  • Law 6 Continuing growth
  • Law 7 Declining quality
  • Law 8 Feedback system

Lehmans Laws of Evolution
  • Law 1 Continuing change
  • "An E-type program that is used in a real-world
    environment must be continually adapted, else it
    becomes progressively less satisfactory"
  • Reasons
  • Evolution of the environment (operational
  • Hence, increasing mismatch between the system and
    its environment
  • Remark
  • E-type programs E for Evolutionary
  • Real-world problem Stakeholders mainly human
  • Requirements and environment continuously
  • Continuous need for change

Lehmans Laws of Evolution
  • Law 2 Increasing complexity
  • "As a program is evolved its complexity increases
    unless work is done to maintain or reduce it."
  • Reasons
  • Small changes are applied in a step-wise process
  • Each patch makes sense locally, not globally
  • Effort needed to reconcile accumulated changes
    with the overall performance goals
  • techniques like refactoring and performance
    optimisation are needed

Lehmans Laws of Evolution
  • Law 3 Self regulation
  • "Program evolution is a self-regulating process.
    System attributes such as size, time between
    releases and the number of reported errors is
    approximately invariant for each system release."

Lehmans Laws of Evolution
  • Law 4 Conservation of Organisational Stability
    (invariant work rate)
  • "The average effective global activity rate on an
    evolving system is invariant over the product
    life time."
  • Reasons
  • Managerial decisions (on effort) are constrained
    by external forces (e.g., resources, complexity)
  • In practice, the effective effort invested
    converges to a constant

Lehmans Laws of Evolution
  • Law 5 Conservation of Familiarity
  • "Over the lifetime of a system, the incremental
    change in each release is approximately constant."

Lehmans Laws of Evolution
  • Law 6 Continuing Growth
  • "Functional content of a program must be
    continually increased to maintain user
    satisfaction over its lifetime."
  • Implies the first law, except with focus on
    functional requirements
  • often one cannot afford to omit existing
  • omitted attributes will become the bottlenecks
    and irritants in usage as the user has to replace
    automated operation with human intervention.
    Hence they also lead to demand for change

Lehmans Laws of Evolution
  • Law 7 Declining Quality
  • "E-type programs will be perceived as of
    declining quality unless rigorously maintained
    and adapted to a changing operational
  • Implies the first law, except with focus on
    observed reliability
  • Reasons
  • Principle of Software Uncertainty Real world
    outcome of E-type software execution is
    inherently uncertain with precise area of
    uncertainty also not knowable.

Lehmans Laws of Evolution
  • Law 8 Feedback system
  • "E-type programming processes constitute
    multi-loop, multi-level feedback systems and must
    be treated as such to be successfully modified or
  • Emphasis on feedback from team members in an

Lehmans Laws of Evolution
  • Applicability of Lehmans laws
  • Lehmans laws seem to be generally applicable to
    large, tailored systems developed by large
  • Confirmed in more recent work by Lehman on the
    FEAST project
  • It is not (yet) clear whether they are applicable
  • Shrink-wrapped software products
  • Systems that incorporate a significant number of
    COTS components
  • Small organisations
  • Medium sized systems
  • Open source software
Write a Comment
User Comments (0)