The Prototyping Model

• A prototype is a version of a system or part of the system that’s developed

quickly to check the customer’s requirements or feasibility of some design
decisions.
• So, a prototype is useful when a customer or developer is not sure of the
requirements, or of algorithms, efficiency, business rules, response time, etc.
The phases of a prototype are:
• Establish objectives: The objectives of the prototype should be made explicit
from the start of the process. Is it to validate system requirements, or
demonstrate feasibility, etc.
• Define prototype functionality: Decide what are the inputs and the expected
output from a prototype. To reduce the prototyping costs and accelerate the
delivery schedule, you may ignore some functionality, such as response time
and memory utilization unless they are relevant to the objective of the
prototype.
• Develop the prototype: The initial prototype is developed that includes only
user interfaces.
• Evaluate the prototype: Once the users are trained to use the prototype, they
then discover requirements errors. Using the feedback both the specifications
and the prototype can be improved. If changes are introduced, then a repeat
of steps 3 and 4 may be needed.
Prototyping Model

Q u ic k p la n

Quick
Quickplan
plan
u i t o
Communication
Communication

Modeling
Modeling
Quick
Quickdesign
design

oy t
Deployment
Deployment
D e iv y
Delivery
Delivery Co s t r c i
Construction n
e ac Construction
&&Feedback
Feedback ofof f
r t t pe
prototype
prototype
The RAD Model (Rapid Application Development)
Team # n
Modeling
Modeling
business
businessmodeling
modeling
data modeling
data modeling
process modeling
process modeling

Construction
Construction
Team # 2 component
componentreuse
reuse
Modeling automatic
automaticcode
code
Modeling generation
Communication business
Communication businessmodeling
modeling generation
testing
data modeling testing
data modeling
process modeling
process modeling
Planning
Planning Construction
Construction
Team # 1 component Deployment
componentreuse
reuse Deployment
integration
Modeling automatic
automaticcode
code integration
Modeling generation delivery
business delivery
businessmodeling
modeling generation
testing feedback
feedback
data modeling testing
data modeling
process modeling
process modeling

Construction
Construction
component
componentreuse
reuse
automatic
automaticcode
code
generation
generation
testing
testing

60 – 90 days 4
The RAD Model Cont…
• Rapid Application Development
• Emphasizes a short development cycle
• A “high speed” adaptation of the waterfall model
• Uses a component-based construction approach
• May deliver software within a very short time period (e.g. , 60 to 90
days) if requirements are well understood and project scope is
constrained
• The application should be modularized and addressed by separate
RAD teams
• Integration is required
5
The RAD Model - Drawbacks

• For large, but scalable projects, RAD requires sufficient human

resources
• RAD projects will fail if developers and customers are not
committed to the rapid-fire activities
• If a system cannot be properly modularized, building the
components necessary for RAD will be problematic
• If high performance is an issue, and performance is to be
achieved through tuning the interfaces to system components,
the RAD approach may not work
• RAD may not be appropriate when technical risks are high
EVOLUTIONARY SOFTWARE PROCESS MODELS

• Software, like all complex systems, evolves over a period of time

• Business and product requirements often change as development

proceeds, making a straight-line path to an end product is unrealistic

• Evolutionary models are iterative

1. The Incremental Model

2. The Spiral Model
3. The Concurrent Development Model
Incremental Process Models

Communication

Software Functionality and Features

Planning

Modeling (analysis, design)

increment # n
Construction (code, test)
delivery of nth
Deployment (delivery, feedback) increment

increment # 2

delivery of 2nd
increment # 1
increment

delivery of 1st
increment

Project Calendar Time

Fig 3.2: The incremental model 8

Incremental Process Models

• Combines elements of the waterfall model applied in an iterative

fashion
• Each linear sequence produces deliverable “increments” of the
software
• The first increment is often a core product
• The core product is used by the customer (or undergoes detailed
evaluation)
• Based on evaluation results, a plan is developed for the next
increment

9
Incremental Process Models

• The incremental process model, like prototyping and other

evolutionary approaches, is iterative in nature
• But unlike prototyping, the incremental model focuses on the
delivery of an operational product with each increment
• Increments can be planned to manage technical risks

10
The Spiral mode l

• Spiral model is a combination of sequential and prototype

model with a very high emphasis on risk analysis
• This model is best used for large projects which involves
continuous enhancements
• There are specific activities which are done in one iteration
(spiral) where the output is a small prototype of the large
software
• The same activities are then repeated for all the spirals till the
entire software is build
When to Use Spiral
model?
•
When the project is large
•
Where the software needs continuous risk evaluation
•
Requirements are a bit complicated and require continuous
clarification
•
Software requires significant changes
•
Where enough time frame is there to get end user feedback
•
Where releases are required to be frequent.
Advantages of using Spiral Model:

•
Development is fast
•
Larger projects / software are created and handled in a strategic way
•
Control towards all the phases of development.
•
More and more features are added in a systematic way.
•
Software is produced early.
•
Has room for customer feedback and the changes are implemented
faster.
Disadvantages of using Spiral model:

•
Risk analysis is important phase so requires expert
people.
•
Is not beneficial for smaller projects. Spiral may go
infinitely.
•
Documentation is more as it has intermediate phases.
•
It is costly for smaller projects.
The Concurrent Development Model
• Sometimes called concurrent engineering
• Can be represented schematically as a series of framework activities, s/w
engineering actions and tasks, and their associated states
• Defines a series of events that will trigger transitions from state to state for each
of the s/w engineering activities, actions, or tasks
• Applicable to all types of s/w development
• Defines a network of activities
• Events generated at one point in the process network trigger transitions among
the states

17
All activities exist concurrently but reside in
different states.
For example,
• early in a project the customer communication
activity (not shown in the figure) has
completed its first iteration and exists in the
awaiting changes state.
• The analysis activity (which existed in the none
state while initial customer communication
was completed) now makes a transition into
the under development state.
• If, however, the customer indicates that
changes in requirements must be made, the
analysis activity moves from the under
development state into the awaiting changes
state.