Evolutionary Model

Evolutionary development
 Exploratory development
 Objective is to work with customers and to evolve a final
system from an initial outline specification.
 Should start with well-understood requirements.
 The system evolves by adding new features as they are
proposed by customer.
 Throw-away prototyping
 Objective is to understand the system requirements. Should
start with poorly understood requirements
 Develop “quick and dirty” system quickly;

 Expose to user comment;

 Refine;

Until adequate system developed.

 Particularly suitable where:
- detailed requirements not possible;

- powerful development tools (e.g. GUI) available

 Evolutionary development

Concurr ent
activities

Initial
Specification
version

Outline Intermediate
Development
description versions

Final
Validation
version
 Evolutionary development

 Problems
 Lack of process visibility

 Systems are often poorly structured

 Special skills (e.g. in languages for rapid

prototyping) may be required
 Applicability
 For small or medium-size interactive systems

 For parts of large systems (e.g. the user interface)

 For short-lifetime systems

 Prototyping Model

Listen to
customers
Normal or
Customers modified
Build/revise
test-drive Waterfall
mock up
mock-up

 Early versions of the software are for demonstration and

requirements purposes. They are meant to be discarded.
 Users get a feel for the system
 Developers learn how to build the real thing
 Customer may imagine that the prototype is final
 Initial quick fix choices may be carried over to later
development
Spiral Model
 Evaluating the Spiral Model

Emphasises Identifying and managing risks

Quit if the risks can’t be quantified
 Considers entire software life cycle
 Adaptable
 Only suitable for large scale project (cost of risk analysis
is high)
 Requires risk assessment expertise
 Only works for Internal Development (where the plug can
be pulled without contractual issues)
The Concurrent Development
Model
 Comparing Models
Model Strengths Weaknesses
Build-and-Fix Fine for short programs not Inappropriate for nontrivial
needing maintenance programs

Waterfall Disciplined approach Final product may not meet

Document driven client’s real needs

Prototyping Helps to detail user’s The prototype may outlive

requirements its usefulness

Iterative Get early results Promotes May degenerate into

maintenance CABTAB

Spiral Incorporates features from Only suited to large-scale in-

other models house development

Component-based Supports re-use and iteration Expensive in the short term