Professional Documents
Culture Documents
Laws of Software Evolution
Laws of Software Evolution
University of Toronto Department of Computer Science University of Toronto Department of Computer Science
formal
may statement controls the Source: Adapted from Lehman 1980, pp1061-1063
relate production
to
of problem
of real
P-type
Ü Continuing Change
change
world Ä Any software that reflects some external reality undergoes continual change
real PROGRAM or becomes progressively less useful
world abstract Ø change continues until it is judged more cost effective to replace the system
provides
view of world Ü Increasing Complexity
maybe of solution Ä As software evolves, its complexity increases…
interest to compare change Ø …unless steps are taken to control it.
S-type requirements
specification Ü Fundamental Law of Program Evolution
E-type Ä Software evolution is self-regulating
Ø …with statistically determinable trends and invariants
real world
change solution PROGRAM Ü Conservation of Organizational Stability
PROGRAM Ä During the active life of a software system, the work output of a
development project is roughly constant (regardless of resources!)
requirements
abstract Ü Conservation of Familiarity
view of world
specification Ä The amount of change in successive releases is roughly constant
model
1
University of Toronto Department of Computer Science University of Toronto Department of Computer Science
Requirements Growth
Source: Adapted from Davis 1988, pp1453-1455
Alternative lifecycle models
Source: Adapted from Davis 1988, pp1455-1459
Throwaway Prototyping Evolutionary Prototyping
Functionality
Functionality
Ü Davis’s model: User needs User needs
ÄUser needs evolve continuously conventional
Ø Imagine a graph showing growth development
Functionality
of needs over time User needs
Ø May not be linear or continuous
(hence no scale shown)
ÄTraditional development always Inappropriateness
lags behind needs growth
(shaded area)
Ø first release implements only
part of the original requirements Shortfall Time Time
Ø functional enhancement adds new
functionality Incremental Development Automated Software Synthesis
Adaptability
Functionality
Functionality
Ø eventually, further enhancement Lateness User needs
becomes too costly, and a User needs
(slope of line)
replacement is planned Longevity
Ø the replacement also only
implements part of its
requirements, Time
Ø and so on... ts e ed e
en se as ce iver as
em lea ph pla el ph
quir t re ent re nt d ent
re s em d em
fir nc an me nc
ify ha ze ce ha
nt en ee pla en Time
ide fr re Time
© Easterbrook 2004 5 © Easterbrook 2004 6
University of Toronto Department of Computer Science University of Toronto Department of Computer Science
2
University of Toronto Department of Computer Science University of Toronto Department of Computer Science
University of Toronto Department of Computer Science University of Toronto Department of Computer Science
3
University of Toronto Department of Computer Science University of Toronto Department of Computer Science
© Easterbrook 2004
Source: Adapted from Palmer, 1996, p365 13 © Easterbrook 2004
Source: Adapted from Palmer, 1996, p365-6 14
University of Toronto Department of Computer Science University of Toronto Department of Computer Science
© Easterbrook 2004
Source: Adapted from Palmer, 1996, p367-8 15 © Easterbrook 2004
Source: Adapted from Gotel & Finkelstein, 1993, p100 16
4
University of Toronto Department of Computer Science
Problematic Questions
Ü Involvement
Ä Who has been involved in the production of this requirement and how?
Ü Change
Ä At what points in the life of this requirements has working arrangements of
all involved been changed?
Ü Notification
Ä Who needs to be involved in, or informed of, any changes proposed to this
requirement?
Ü Loss of knowledge
Ä What are the ramifications regarding the loss of project knowledge if a
specific individual or group leaves?
© Easterbrook 2004
Source: Adapted from Gotel & Finkelstein, 1997, p100 17