You are on page 1of 12

2/29/2016

Objectives
2

To understand Rapid Application Development


(RAD) by outlining
A brief history of development approaches leading to
it
Rationale
Advantages/Disadvantages
GUI Builders/Designers
Event Driven Programming

Application Programming II
Rapid Application Development and
Prototyping

Rapid Application Development and Prototyping

What is RAD?
3

RAD Approaches
4

Rapid Application Development (RAD) is a


development lifecycle designed to give much faster
development and higher-quality results than those
achieved with the traditional lifecycle. It is designed
to take the maximum advantage of powerful
development software that has evolved recently
(Martin, 1991).
By using a series of proven application development
techniques, within a well-defined methodology,
organisations can quickly and cheaply develop
systems without compromising on quality .
Rapid Application Development and Prototyping

Barry Boems spiral model


James Martin's RAD methodology
Agile methods

Rapid Application Development and Prototyping

2/29/2016

What is RAD?
5

What is RAD?
6

Dr. James Martin came up with the RAD


software development methodology/approach
in the late 1980s.
This was in response to the non-agile Stagewise
or Waterfall Models methodologies of the
1970s.

Unlike the traditional conventional approaches,


RAD emphasises development rather than
specification and planning.
It is thus a flexible and rapid development
process where requirements are modified as
the project progresses and more knowledge is
gained.
For instance, rather than concentrate on design
specifications, RAD uses prototypes.

With

the
previous
methodologies,
large
applications took so long to build that requirements
would change before the system was complete,
resulting in unusable systems.
Rapid Application Development and Prototyping

Rapid Application Development and Prototyping

RAD A Brief History


7

RAD A Brief History


8

The traditional lifecycles of 1970s (still in used


today), are based on a structured step-by-step
approach to developing systems.
Users must sign-off after the completion of each
specification before development can proceed to
the next step.
After this the requirements and design are rigid.
The system is then coded, tested, and implemented.

Rapid Application Development and Prototyping

Traditional SW Dev Methods Disadvantages


Rigid, cascading, one-way steps of development.
A long delay before the customer gets to see any
results
There is nothing until 100% of the process is
finished, then 100% of the SW is delivered.
The development process can take so long that the
customers business could fundamentally change
before the system is even ready for use.
Rapid Application Development and Prototyping

2/29/2016

RAD A Brief History


9

RAD A Brief History


10

In 1986, to try and eliminate these challenges, Barry Boehm,


at the time a Chief SW Engineer at TRW (a former US
aerospace and automotive company), later a prof at USC,
defined his Spiral Model.
The Spiral Model is a risk based approach which combines
characteristics of evolutionary prototyping with the Waterfall
Model

1.
2.
3.
4.

Through his model, Boehm first implemented software prototyping


as a way of reducing risk.

5.

The development process of the Spiral Model separates the


product into critical parts or levels while performing risk
analyses, prototyping, and the same steps at each of these
levels. Rapid Application Development and Prototyping

6.

The Spiral Model iterates cycles of the following


project cycles:
Requirements definition
Risk analysis
Prototyping
Simulate, benchmark
Design, implement, test
Plan next cycle if any.

See diag on next slide


Rapid Application Development and Prototyping

RAD A Brief History


12

The Evolutionary Life Cycle, developed by Tom


Gilb, is based on an evolutionary prototyping
rationale where the prototype is grown and
refined into the final product.
These 2 models led to the Rapid Iterative
Production
Prototyping
(RIPP)
model
developed at DuPont (an American chemical
company) in the mid-to-late 1980s.

11

Rapid Application Development and Prototyping

Rapid Application Development and Prototyping

2/29/2016

RAD A Brief History


13

James Martin used this work as a basis for his larger,


more formalized process, Rapid Application
Development (RAD).
RAD compresses the step-by-step development of
conventional methods into an iterative process.
The RAD approach thus includes developing and
refining the data models, process models, and
prototype in parallel using an iterative process.

User requirements are refined, a solution is designed,


the solution is prototyped, the prototype is reviewed,
user input is provided, and the process begins again.
Rapid Application Development and Prototyping

RAD can actually be thought of as a variation on JAD as it creates an application more


quickly through such strategies as using fewer formal methodologies and reusing
software components (techtarget.com)

RAD Rationale
15

Rapid Application Development and Prototyping

14

RAD Rationale
16

1.

2.

3.

Use RAD when you want to:


Converge early toward a design acceptable to the customer
and feasible for the developers
Limit a projects exposure to the forces of change

as it shortens the development cycle and limits the cost of change by


incorporating it up-front before large investments are made
in development and testing.

unlike the Waterfalll model which cannot handle changes in the


environment with its fixed specifications and design

Save development time, possibly at the expense of economy


or product quality
Rapid Application Development and Prototyping

RAD Is NOT a Magical Solution For


Preventing:
1. Cost overruns
2. Runaway schedules
RAD needs a team already disciplined
in (i) cost management and (ii) time
management.

Rapid Application Development and Prototyping

2/29/2016

17

SCHEDULE versus ECONOMY


versus PRODUCT QUALITY

18

Tradeoffs determine the pace of development.

A.

SCHEDULE versus ECONOMY


versus PRODUCT QUALITY
B.

Efficient Development: balances economy, schedule, and quality

1.

a.

Schedule -- faster than average

b.

Economy -- costs less than average

c.

Product -- better than average quality

1.

Sensible RAD: tilts away from economy and quality toward fastest schedule

2.

a.

Schedule -- much faster than average

b.

Economy -- costs a little less than average

c.

Product -- a little better than average quality

2.

All-out RAD: "code like hell (fast, loose, all-as-you-go coding i.e. Code-&-Fix)

3.

a.

Schedule -- fastest possible

b.

Economy -- costs more than average

c.

Product -- worse than average quality

For RAD, something other than schedule must be


negotiable.
RAD has a fair chance of success if the customer will
negotiate either economy or quality
RAD has a better chance for success if the customer will
negotiate both economy and quality
NOTE:
Negotiating quality does NOT mean accepting a higher
defect rate.
It means accepting a product that is less usable, less fullyfeatured, or less efficient.
Rapid Application Development and Prototyping

Rapid Application Development and Prototyping

19

SCHEDULE versus ECONOMY


versus PRODUCT QUALITY
C.

1.

So, with RAD, one or more of the following goals


may be unachievable.
the fewest possible defects

2.

the highest possible level of customer satisfaction

3.

(because developers may not have the legal right to


modify the source for some plug-in components)
(because secondary requirements may be sacrificed to
stay on schedule)

the lowest development costs

(because buying reusable components may cost more than


building)
Rapid Application Development and Prototyping

The RAD SW Dev Approach


20

large applications took so long to build that requirements would change


before the system was complete, resulting in unusable systems

RAD tries to mitigate this problem through

prototyping,

iterative development,

Timeboxing (restricting to a specific duration)

in time management, allocating a fixed time period (a timebox) to each


planned activity.

small teams,

an active management approach, and

the use of Computer Aided Software Engineering (CASE) tools.

E.g. to develop models (using eg UML diagrams) and directly generate code
based on those models instead of hard coding.
Rapid Application Development and Prototyping

2/29/2016

21

The Martin approach to RAD


includes four phases:

RAD Phases
22

Requirements Planning Stage

User Design Stage

Defines the business functions and data subject areas that the system will
support and determines the systems scope.
uses workshops to
model the systems data and processes and to
build a working prototype of critical system components.

Construction Stage

completes the construction of the physical application system, builds the


conversion system, and develops user aids and implementation work plans.

Implementation Stage

includes final user testing and training, data conversion, and the
implementation of the application system.

Rapid Application Development and Prototyping


Rapid Application Development and Prototyping

Characteristics of RAD
23

Characteristics of RAD
24

1.

RAD uses hybrid teams

1.

Teams should consist of about 6 people, including

both

developers and
users of the system plus
anyone else who has a stake in the requirements.
fulltime

Developers chosen for RAD teams should be allrounders

They should be analysts, designers and programmers


all rolled into one.
Rapid Application Development and Prototyping

RAD uses hybrid teams (cont)


Key players in a RAD project
Sponsor: A high-level user executive who funds the system and
is dedicated to both the value of the new system and to
achieving results quickly.
User Coordinator: A user appointed by the Sponsor to oversee
the project from the user perspective.
Requirements Planning Team: A team of high-level users who
participate in the Joint Requirements Planning workshop.
User Design Team: A team of users who participate in the
design workshop.
Rapid Application Development and Prototyping

2/29/2016

25

Characteristics of RAD
1. RAD uses hybrid teams (cont)

Characteristics of RAD
26

User Review Board: A team of users who review the system after
construction and decide whether modifications are necessary before
cutover.

Training Manager : The person responsible for training users to


work with the new system.

Project Manager: The person who oversees the development effort.

Construction (SWAT) Team (Skilled Workers with Advanced Tools)


Team: a small team of two to six developers who are highly trained
to work together at high speed.

Workshop Leader: The specialist who organises and conducts the


workshops for Joint Requirements Planning and Joint Application
Design.

RAD uses specialised tools that support

2.

Visual development.
Creation of fake prototypes (pure simulations)
Creation of working prototypes.
Multiple languages.
Team scheduling.
Teamwork and collaboration.
Use of reusable components
Use of standard APIs
Version control

Rapid Application Development and Prototyping

(as many versions will be generated)


Rapid Application Development and Prototyping

Characteristics of RAD
27

Characteristics of RAD
28

2.

RAD uses specialised tools


Uses both computerised tools and human techniques to
achieve the goals of high-speed and high quality.
CASE tools are a good example of tools that can be used
in RAD projects.
These tools play a key role in eliminate some problems
that exist in other models of software development.

E.g., CASE tools can be used to

develop models (using e.g. UML diagrams) and


directly generate code based on those models instead of hard coding.

RAD uses iterative, evolutionary prototyping

3.

i.

JAD (Joint Application Development) meeting: Highlevel end-users and designers meet in a brainstorming
session to generate a rough list of initial requirements.
Developers
Customers

ii.

talk and listen


talk and listen

Iterate until done


Developers

build/ evolve prototype based on current


requirements.
Designers review the prototype.
Customers try out the prototype, evolve their requirements
Rapid Application Development and Prototyping

Rapid Application Development and Prototyping

2/29/2016

Characteristics of RAD
29

Notes on Characteristics of RAD


30

Iterate until done (cont)

FOCUS GROUP meeting: customers and developers meet to


review product together, refine requirements, and generate
change requests.
Developers listen.
Customers talk.
Requirements and change requests are timeboxed".

Iterations require between 1 day and 3 weeks.


At some stage, exploratory prototypes may evolve into
operational prototypes.
Focus Group Sessions

Restricted to a specific duration

last about 2 hours


are led by an experienced facilitator, who keeps the group "on
focus

Changes that cannot be accommodated within existing


timeboxes are eliminated.
If necessary to stay "in the box", secondary requirements
are dropped.

by having clear goals regarding the kind of information that needs to be


elicited
by preparing an issue-oriented agenda in advance of the meeting
by ensuring that adequate discussion is directed toward each issue
by ensuring everyone has an adequate opportunity to participate

are followed by a report from the facilitator

Rapid Application Development and Prototyping

Rapid Application Development and Prototyping

Constraints of RAD
31

Constraints of RAD
32

The criterion for acceptance of deliverables


must be fitness for a business purpose".
i.e.

Build the right product before you build it


right.

All constituencies that can impact application


requirements must have representation on the
development team throughout the process.

Rapid Application Development and Prototyping

Customers, developers and management must


accept informal deliverables.
Paper

prototypes rather than full-scale systems


from user workshops rather than formal
requirements documents
Notes from designers' meetings rather than formal
design documents
PRINCIPLE: Create the minimum documentation
necessary to facilitate future development and
maintenance.
Notes

Rapid Application Development and Prototyping

2/29/2016

Constraints of RAD
33

Constraints of RAD
34

Development teams must be empowered to make some


decisions traditionally left to management.

End-to-end timescale must be 6 months or less.


Iteration must be used in such a way that the
development process converges towards an
acceptable business solution.
must
incorporate
evolving
Prototyping
requirements quickly, in real time, and gain
consensus early.
There must be a buy before build" bias.

Traditional teamwork: the project manager controls everything.


Responsible for all decisions and plans.

Makes sense if you can only trust one person with this power.

Does NOT make sense if you have a team of good people as it becomes
inefficient and inhibits working at full potential.

Single authority bottlenecks decisions.

The team must include all the necessary team members to make
decisions, and make them in a timely manner.

In order to ensure that it is their responsibility to deliver the product and


that they have complete ownership.

Any interference with the project team is disruptive and reduces their
motivation to deliver.

Buying of reusable components


Rapid Application Development and Prototyping

Rapid Application Development and Prototyping

RAD Is Successful When


35

RAD Is NOT Successful When


36

The application will be run standalone.


Preexisting class libraries (APIs) can be majorly used.
Performance is not critical.
Products distribution will be narrow (in-house or vertical market).

Project scope (macro-schedule) is constrained.


Reliability is not critical.
Systems can be split into several independent modules.

Vertical market: vendors offer goods and services specific to an industry,


trade, profession or other customers with specialised needs .

Parallelism thus possible

The product is aimed at a highly specialised IS (Information System)


market.

Application must interoperate with existing programs.


Few plug-in components are available.
Optimal performance is required.
Product development cant take advantage of high-end IS
tools (e.g., 4GLs).
Product distribution will be wide (horizontal or mass
market).

a market in which a product/service meets a specific need of


a wide range of buyers across different sectors.

RAD becomes QADAD (Quick And Dirty Application


Development).
Rapid Application Development and Prototyping

Rapid Application Development and Prototyping

2/29/2016

RAD Is NOT Successful When


37

RAD methods are used to build

An Evaluation of RAD

38

operating systems (reliability target too high for RAD),


computer games (performance target too high for
RAD).

Strengths and Weaknesses

Technical risks are high due to use of


bleeding edge technology.
The product is mission or life-critical.
The system cannot be modularized

defeats parallelism
Rapid Application Development and Prototyping

Rapid Application Development and Prototyping

RAD Strengths
39

RAD Strengths
40

Buying may save money compared to building.


Deliverables are sometimes easier to port

Development conducted at a higher level of


abstraction

because they make greater use of high-level abstractions,


scripts, intermediate code

because RAD tools operate at this level

Early visibility

Greater flexibility

Greatly reduced manual coding

Increased user involvement

Possibly fewer defects

because developers can redesign almost all will


because of wizards, code generators, code reuse
because they are represented on the team at all times
because CASE tools may generate much of the code

because of prototyping
Rapid Application Development and Prototyping
Rapid Application Development and Prototyping

10

2/29/2016

RAD Strengths
41

RAD Disadvantages
42

Buying may not save money compared to building.


Cost of integrated toolset and hardware to run it.
Harder to gauge progress

Less efficient

Loss of scientific precision

Possibly reduced cost

because

time is money, also because of reuse

Shorter development cycles

because

development tilts towards schedule and


away from economy and quality

Standardised look and feel


because

APIs and other reusable components give


a consistent appearance.

Rapid Application Development and Prototyping

because code isnt hand crafted


because no formal methods are used

Rapid Application Development and Prototyping

RAD Disadvantages
43

because there are no classic milestones

RAD Disadvantages
44

May accidentally empower a return to the


uncontrolled practices of the early days of
software development.
More defects

because

Prototype may not scale up, a B-I-G problem


Reduced features
of timeboxing, software reuse

Rapid Application Development and Prototyping

Reliable on third-party components may

sacrifice needed functionality

add unneeded functionality

create legal problems

Requirements may not converge

of the code-like-hell syndrome

because

because the interests of customers and developers may diverge from


one iteration to the next)

Standardised look and feel

Successful efforts difficult to repeat (no two projects evolve the


same way)
Unwanted features (though reuse of existing components)

undistinguished, lackluster appearance

Rapid Application Development and Prototyping

11

2/29/2016

Summary
45

In order to ensure high responsiveness, projects are designed with


fixed timescales, sacrificing functionality if necessary.

This allows the development team to focus on the pieces of functionality


that have the highest business value, and deliver that functionality
rapidly.

Change is
development.

often

the

reason

for

delays

in

application

In long linear development processes, changes in functionality requirements or


project scope, particularly after a lot of time has been invested in planning, design,
development and testing, cause many months to be lost and significant expense to
be incurred for redesigning and redevelopment.

RAD combats scope and requirements creep by limiting the project's exposure to
change - shortening the development cycle and limiting the cost of change by
incorporating it up-front before large investments are made in
development and testing..
Rapid Application Development and Prototyping

12

You might also like