Rapid Application Development

techniques
An overview
 A number of techniques are used in RAD
environments.
 It is the use of these techniques, together
with the underlying philosophy of RAD, that
enable Rapid Application Development to
successfully take place.
 The techniques we will be examining are:
 Prototyping
 JAD
 Timeboxing
What is Prototyping?
A definition:
 The process of building an experimental
system quickly and inexpensively for
demonstration and evaluation so that users
can better determine information
requirements.
 Prototyping is an iterative process.
 A process of repeating the steps to build a
system over and over again.
What does it address?
 Some of the problems of traditional
systems analysis:
 users only saw their information systems at
point of implementation
 Systems Analyst was really experimenting
on the user
 System doesn’t always do what the users
were expecting it to do.
Why prototype?
 It is a response to user dissatisfaction
found when using traditional approaches
 It is seen as an improved form of systems
investigation & analysis. Particularly
useful where:
 application area is not well defined
 organisation not familiar with the technology
 communication between analysts & users
has not been good.
Why prototype? (cont.)
 Cost of rejection by users would be very high
and is essential to ensure that the final
version has got users’ needs right.
 There is a requirement to assess the impact
of prospective information systems.
Evolutionary or throwaway?
 Atthe end of the prototyping cycle there
are two choices to be made:
 Throwaway the prototype but use the
prototype design as the basis for building an
operational system - usually in a different
software environment (throwaway)
 Develop the prototype into a fully working
system that will become operational within
the organisation (evolutionary)
Evolutionary or throwaway (2)
 Approach taken depends upon:
 Software environment required for final
operational system
 How much of the final system is to be
prototyped
 Whether there is time to redevelop the
system using another software environment
Basic prototyping cycle

Identify basic Develop a

Reqs. Working Use prototype
prototype

YES
Happy?

Revise and
Operational
enhance
prototype
prototype NO
Different types of prototype(1)
 Different types with different objectives
 Requirements analysis prototypes
 Examine areas where users and analysts are
unsure of requirements
 Look at a physical approximation of a system to
gather ideas
 Prototyping viewed as a an improvement on
traditional requirements gathering techniques
Different types of prototype(2)
 Functional prototypes
 These are used for demonstrating, testing and
evaluating the functionality of a system
 Process prototypes
 These are used for demonstrating, testing and
evaluating the processes, sequences, responses
etc. of a system
 Design prototypes
 For demonstrating and evaluating a variety of
alternate designs or solutions
Different types of prototype(3)
 Performance prototypes
 These are used for testing, response times,
loads, volumes etc.
Problems with prototyping
 Must be properly managed and controlled
 Too many iterations can lead to a ‘runaway project’.
 Between 3 – 5 iterations is usually considered
sensible.
 Prototyping can lead to the proliferation of
requirements
 It can be difficult to get good user participation
 Lack of management commitment
 Users not given sufficient time or incentive to co-
operate
Problems with prototyping
cont..
 Expectations with the prototyping process
can be too high
 Users may think that they will definitely get the
system they want thru prototyping process
 Prototype originally designated as
‘throwaway’ may become operational
 Documentation may be neglected because

‘it was only supposed to be a prototype’.

Prototyping – things to
remember
 Prototyping must be carefully managed
 There must be understanding of, and

commitment to, the process by both

management and users.
 Controls during the prototyping process

must be maintained
 Prototyping is not a substitute for

thorough analysis and design

JAD (Joint Application Development)
Faciliated Workshops

 Basic idea is to:

 select key end users
 Conduct workshops that progress thru structured
set of steps for planning and designing a system

 Most methods now take Facilitated

workshop to be any point in development
process from inception to delivery
Faciliated Workshop – what’s
it all about?
 Aim of a Facilitated Workshop is to
produce something and to achieve
consensus among participants as to the
content of that thing.
 Particularly useful at beginning of project,
when trying to define scope etc.
 It is a facilitated meeting designed to
overcome the problems of traditional
requirements gathering.
 Aim to specify high-level requirements
Who attends a Facilitated
Workshop?
 Differenttypes of personnel must be
involved in a Facilitated Workshop:
 Executive sponsor – the person who has
made a commitment to getting the system
built. Kicks the meeting off, doesn’t interfere!
 RAD workshop leader – does preparation,
leads the workshop etc.
 I.S professionals – should be one or more of
these. Must be involved in the project
Who attends a Facilitated
Workshop?
 End users - those commandeered to the
project development plus other end-user
reps.
 Scribe – person responsible for the project
documentation. Minutes this workshop or
builds models using case tool etc….
 Visiting specialists – Specialists may attend
sessions as and when required
 Project manager - may be present but
shouldn’t lead the session……
Reasons for using Facilitated
Workshops
 Harness know-how of users
 Cut across organisational barriers

 Group dynamics drive the design

 Organised, controlled, structured process

 Experienced session leader facilitates

discussion & drives the session to complete

its agenda
 Includes management direction

 Utilises I.S advice and perspective

Timeboxes
 How we manage a RAD project is key to
its success.
 We consider a product-based view

rather than an activity-based view.

 RAD is achieved through the use of

timeboxes which help us manage

incremental development
Timeboxes – some definitions
 Product-based view
 This is where the project is driven by
completion of a particular delivery (product)
e.g. “ in two weeks time I will have delivered
the order entry input screens and
processing”.
 Activity-based view
 This is where the project is driven by
activities that must be completed. E.g. “in two
weeks time I will have finished modelling the
user requirements”.
Timeboxes – some more
definitions
 Incremental delivery
 Operational parts of the system are delivered
over a period of time rather than the complete
system being delivered in one go.
 Timeboxes
 A mechanism for managing the development
and delivery of part of the functionality of an
operational system within a pre-determined
time scale.
Timebox in detail
 It is a fixed timescale for a particular RAD
activity e.g. develop mortgage quotation
functionality for an online mortgage service
 The deadline is immovable
 Developers and users both agree that some
functionality will be delivered by the deadline
 this means that through
prototyping/incremental development
something that is useable and of importance
is delivered by the deadline
RAD and timeboxing
 High level requirements are determined
 System to be developed is then divided
into a number of components or
timeboxes based on priority of the
requirements.
 Most important requirements are those
with the largest potential benefit.
 These are developed in first timebox
 System is prioritised into a number of
timeboxes
RAD and timeboxing
continued
 90 days often considered maximum time
for a timebox.
 Something workable must be delivered

within the timebox.

 RAD partitions the development and

delivers something quickly and often.

 Being late is not an option
Development – time and
resources
Traditional dev’t DSDM dev’t

functionality resources time

Fixed

Variable
resources time functionality
Prioritising development for
timeboxes (MoSCoW rules)
Must have for requirements that are
fundamental to the system
Should have for important requirements that
would probably be classed as mandatory in a
less time-constrained environment
Could have for requirements that can more
easily be left out of the increment under
development
Want to have but will not have this time round
for those valuable requirements that can wait
until later development takes place
More on MoSCoW rules
 Allof these requirements are needed for
the full system.
 These rules are used to provide the basis

upon which decisions are made about

what the developers will do over the
whole project and during any timebox
within the project
Can you deliver key requirements
in short amount of time?
 Yes, according to the 80:20 rule (also called
the Pareto principle).
 This states that 80% of the functionality can be
delivered in the first 20% of the time.
 The last 20% of the functionality (probably the
tricky bits!) take up 80% of the time
 On this principle, you can timebox 80% of the
functionality and deliver it quickly (partial delivery)
 The remaining functionality can be delivered at a
later date
In summary (1)
 There are a number of key techniques
associated with Rapid Development
(Agile methods)
 Prototyping
 Facilitated workshops
 Timeboxing
 MoSCoW rules
 Thesetechniques can be used
standalone as well as part of RAD
In summary (2)
 These techniques are designed to:
 Incorporate users into all stages of the life
cycle
 Enable an incremental approach to
development
 Enable an iterative approach to delivery