1. An introduction to the 'evolutionary delivery' method
Principles of Software Engineering Management
Chapter 7
By Tom Gilb (1988)

2. “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

3. “Current” Models (1988) System Analysis Design Plan & Budget Build
Test
Run
Maintain

4. 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

5. Revolutionary/Evolutionary Delivery
Revolutionary Model
Evolutionary Model

6. The Evolutionary Method
Set Objectives
Rough Evolutionary Plans
Engineer the Step
Construct the Planned Step
Deliver to Real Users
Analyze Results

7. Concepts of the evolutionary method
Planning for multiple objectives
Early, frequent iteration
Complete analysis, design, build and test at each step
User orientation
System approach instead of algorithm orientation
Open-ended basic system architecture
Result orientation instead of development process orientation

8. 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

9. 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

10. 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

11. 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)

12. The Evolutionary Method
Set Objectives
Rough Evolutionary Plans
Engineer the Step
Construct the Planned Step
Deliver to Real Users
Analyze Results

13. Conventional Software Development Evolutionary Delivery
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

14. 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)

15. 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

16. 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

17. 7. Result orientation instead of development process orientation
Requirements
Attributes
How well?
Qualities (Benefits):
Workability
Availability
Adaptability
Usabilty
Resources (Limits):
Other
Tools
People
Time
Money
Functions
What?

18. 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

19. 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

20. 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

21. 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

22. 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
each step should provide some immediate useful results (ideally the planned benefits)
if you first implement the most promising (useful-to-user) parts, each step will be useful in some way

23. 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

24. 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

25. Objections to Evolutionary Delivery
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
our system can't be divided into smaller steps

26. Objections to Evolutionary Delivery
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
we are in a hurry

27. Objections to Evolutionary Delivery
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
management won't like it

28. Objections to Evolutionary Delivery
then they are not good designers, hire others instead!
or, train your designers to deliver evolutionary designs
our designers can't make evolutionary plans

29. Objections to Evolutionary Delivery
THEN IT SHOULD BE!
it is not the traditional way to design and plan in our company

30. Objections to Evolutionary Delivery
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
The extra effort of moving from step to step costs more than doing it all at once

31. 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”