An introduction to the
'evolutionary delivery' method
Principles of Software Engineering
Management
Chapter 7
By Tom Gilb (1988)
“Current” Models (1988)
• most models of software engineering are
based on the "waterfall model" for delivery
– single delivery date
– prototypes are "throw away“ (no reworking)
– analysis and design before code and test
“Current” Models (1988)
System Analysis
Design
Plan & Budget
Build
Test
Run
Maintain
The Evolutionary Method
• Divide and conquer
– deliver something to a real end-user
– measure added value to user
– adjust design and objectives
• An “eternal cycle” of modifying an existing
system rather than building a new one
• Reduces risk
– simpler to modify
– easier to test
Revolutionary/Evolutionary Delivery
Revolutionary Model
Evolutionary Model
The Evolutionary Method
Engineer the Step
Set Objectives
Rough Evolutionary
Plans
Construct the
Planned Step
Deliver to Real Users
Analyze Results
Concepts of the evolutionary method
1. Planning for multiple objectives
2. Early, frequent iteration
3. Complete analysis, design, build and test at each
step
4. User orientation
5. System approach instead of algorithm
orientation
6. Open-ended basic system architecture
7. Result orientation instead of development
process orientation
1. Planning for multiple objectives
Conventional Software Development
•function oriented
•control of quality and resources is less important
•lack of knowledge about defining and measuring
"usability" or "maintainability”
Evolutionary Delivery
•iterations towards clear, measurable, multidimensional
objectives
•functional, quality and resource objectives are defined
•projects are more related to real world needs of user
2. Early, frequent iteration
Conventional Software Development
•Delivery of first practical/useful results is at least one year ahead
•Cycle before first delivery could be divided into many (10-100)
smaller and earlier steps
•Phased planning – not exactly evolutionary
Evolutionary Delivery
•Focus on accomplishing something useful with minimum
resources, not on accomplishing as much as possible within a
(budget/deadline/etc) constraint, like in phased planning
•Select the right parts for early implementation- parts with high
user-value to development-cost ratio
financial user value
high-risk parts
parts that convince users that program is useful
3. Complete analysis, design, build
and test at each step
Conventional Software Development
•Waste time in
requirement analysis
detailed design
full coding and testing phases
•Assume that detailed analyzing before construction
prevents construction errors
•Difficult to do accurately for big software projects:
too many unknowns
too many dynamic changes
complex set of interrelations
•Negative feedback at delivery  many resources were
committed to the wrong solutions
3. Complete analysis, design, build
and test at each step
Evolutionary Delivery
•set initial objectives, but be prepared to modify them
•set measurable objectives for each next delivery phase
could also be modified if necessary
compromise and tradeoff: not all objectives are fully met
•design, build and test immediate technical solution
•deliver solution, get feedback and use it to modify:
immediate design and architectural ideas
short/long-term objectives
•gives us early warning signals for problems with software
•start with ‘open ended’ architecture (easy to modify and
adapt)
The Evolutionary Method
Engineer the Step
Set Objectives
Rough Evolutionary
Plans
Construct the
Planned Step
Deliver to Real Users
Analyze Results
4. User Orientation
Conventional Software Development
•orientation towards machine/algorithm/deadline, not user
•usually developers don’t see real end users using software
•even if developers were more user-oriented, by the time
they understand users’ needs it might be too late
Evolutionary Delivery
•developers must listen to user reactions early and often
be mentally, economically and technically prepared to
listen to users
•user values are dynamic
alter as users get experience
parts that are selected for development may change
5. System approach instead of
algorithm orientation
Conventional Software Development
•more focus on algorithm and programming language
•little focus on data engineering, documentation, marketing
Evolutionary Delivery
•architecture coordination of design process as a whole
•a method that is suited for any creative process (not merely
software engineering)
6. Open-ended basic system
architecture
Evolutionary Delivery
•open architectures are essential, because they enable us to
avoid problems with software maintenance
•principle attributes of a system should allow it to survive and
succeed with changes over time:
maintainability
portability
extendibility
•a good software engineer should constantly keep up with
available design technologies that lead to more adaptable
systems
7. Result orientation instead of
development process orientation
Conventional Software Development
The process seems more important than the result, because
there are no clear objectives on which to focus effort
Evolutionary Delivery
•sets clear objectives regarding quality and resources
•constant measure of progress towards the goals
7. Result orientation instead of
development process orientation
Requirements
Qualities (Benefits):
Workability
Availability
Adaptability
Usabilty
Attributes
Functions
How well?
What?
Resources (Limits):
Time
People
Money
Tools
Other
Not Knowing, Chess and Driving
It is fine not to know everything at any given time of the
development process
evolutionary delivery is like chess: have a
strategy, but respond to immediate
realities (opponent's last move)
“there is only one move that really
counts: the next one”
evolutionary delivery is like driving a car:
we must plan our driving, but we should
not necessarily drive the way we planned
Small is Beautiful
• The problem of result control:
the outcome of implementing a software project is
difficult to predict
unexpected results affect the project attributes (usually
"in the wrong direction“)
• Solution: keeping implementation steps small and simple
Like a scientific experiment: keep constant all factors
but one, vary just one factor, and test its impact
• It is easier to deal with the effect of one small increment of
the solution than it is to understand the impact of the
entire solution
Characteristics of Evolutionary Steps
• traditional phased projects are created by
making phases as large as could be fit
within a given budget
• with evolutionary delivery, we create
smaller phases that achieve maximum value
with minimum cost
Characteristics of Evolutionary Steps
• The system only gets some kind of reality after
the delivery of the first sub-step
• After the initial delivery stage we analyze:
how long did it take
what unexpected resources did it consume
is the design on the right path, or do we
have to change concepts
Characteristics of Evolutionary Steps
each step should have a
retreat path
each step is an experiment for
assessing what
should/shouldn't be done on
a larger scale
Evolutionary
Steps
each step should provide
some immediate useful
results (ideally the planned
benefits)
if you first implement the
most promising (useful-touser) parts, each step will be
useful in some way
Planning Evolutionary Steps
• It is not always possible to pre-plan the best
set of steps, since it is not possible to know
which user requirements will change
• it is probably best to ask at each step, "what is
now the next best step?“
• feedback and real-world data that is provided
by each step should be used for planning
subsequent steps
Project Estimates and
Evolutionary Design
• Evolutionary design leads to dynamic planning, since
estimates are constantly being improved
plans made with evolutionary method are more realistic
than plans that are made in detail before the beginning of
the process
real results will correspond closely with the latest adjusted
estimates
• Planning is like a model of the real world at a particular
point in time – idealized and simplified
• Evolutionary planning closes the gap between theory
and reality
planners are more aware of effects of the plan on the
budget, resources and satisfactions of clients
Objections to Evolutionary Delivery
our system
can't be
divided into
smaller
steps
• almost any project was found to be
possible for division into interesting steps
• if you think a project is too small for
division, you might be under-estimating
its size
• sometimes evolutionary design is done by
initially improving an existing system,
then turning it into a new system
• If a certain design is wrong for
evolutionary delivery, maybe creating a
totally different design architecture is a
better idea
Objections to Evolutionary Delivery
we are in a
hurry
• the current estimation of delivery
date is probably optimistic…
• evolutionary design allows to
deliver the most critical results
much earlier
• Probably, the entire long-range
solution will be delivered earlier
than with other delivery methods
Objections to Evolutionary Delivery
management
won't like it
• people assume that the management
won't like the fact that long term planning
and cost estimations are initially done
only roughly
• management might prefer it, because
they don’t commit resources to a
doubtful result, or put faith in long-term
results
• if we fail, we lose little, if we succeed we
make a big progress for the organization
• early phase deliveries allow payback from
the project shortly after it starts
Objections to Evolutionary Delivery
our
designers
can't make
evolutionary
plans
• then they are not good
designers, hire others
instead!
• or, train your designers to
deliver evolutionary
designs
Objections to Evolutionary Delivery
it is not the
traditional way to
design and plan in
our company
THEN IT
SHOULD BE!
Objections to Evolutionary Delivery
The extra effort
of moving from
step to step
costs more than
doing it all at
once
• true only for systems with a 'closed
end' architecture, that are hard to
modify
• an evolutionary architecture
presupposes that many changes will
be made to the design during the
process, thus allows modifications to
be done much more easily
• problems of inflexible design usually
show up in the early steps of the
process  can be solved early on
My Personal Objections
• constant cycles of changes in the system are
difficult for the users
– For users, the revolutionary method has many
advantages
• getting valuable feedback from real end-users
is not easy
• at the end of the project might leave “corners”