An introduction to the 'evolutionary delivery' method

Principles of Software Engineering Management

Chapter 7By 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

Set Objectives

Rough Evolutionary Plans

Engineer the Step

Construct the Planned Step

Deliver to Real Users

Analyze Results

Concepts of the evolutionary method

1. Planning for multiple objectives2. Early, frequent iteration3. Complete analysis, design, build and test at each

step4. User orientation5. System approach instead of algorithm orientation6. Open-ended basic system architecture7. Result orientation instead of development

process orientation

1 .Planning for multiple objectivesConventional 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 iterationConventional 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 valuehigh-risk partsparts that convince users that program is useful

3. Complete analysis, design, build and test at each step

Conventional Software Development• Waste time in

requirement analysisdetailed designfull coding and testing phases

• Assume that detailed analyzing before construction prevents construction errors• Difficult to do accurately for big software projects:

too many unknownstoo many dynamic changescomplex 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 ideasshort/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

Set Objectives

Rough Evolutionary Plans

Engineer the Step

Construct the Planned Step

Deliver to Real Users

Analyze Results

4 .User OrientationConventional 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 dynamicalter 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:

maintainabilityportabilityextendibility

•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 DevelopmentThe 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

AttributesHow well?

Qualities (Benefits):WorkabilityAvailabilityAdaptabilit

yUsabilty

Resources (Limits):Time

PeopleMoneyToolsOther

FunctionsWhat?

Not Knowing, Chess and DrivingIt 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 predictunexpected 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 takewhat unexpected resources did it consumeis the design on the right path, or do we

have to change concepts

Characteristics of Evolutionary Stepseach step should have a retreat path

each ste

p is a

n ex

peri

me

nt f

or assessi

ng

what s

houl

d/s

houl

dn't

be

done

on a larger scale

each ste

p s

houl

d

pr

ovi

de s

ome i

mme

diate

usef

ul res

ults (i

deally t

he

pla

nne

d

be

nefits)

if y

ou first i

mple

me

nt t

he

most

pr

omisi

ng (

usef

ul-t

o-

user)

parts, eac

h ste

p

will

be

usef

ul i

n s

ome

way

Evolutionary Steps

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 improvedplans made with evolutionary method are more realistic than

plans that are made in detail before the beginning of the processreal 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

realityplanners are more aware of effects of the plan on the budget,

resources and satisfactions of clients

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

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

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

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

Objections to Evolutionary Delivery

THEN IT SHOULD BE!

it is not the traditional way to design and plan in

our company

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

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”