RAD

advertisement
SDLC – Traditional Waterfall Approach to IS development:



Emphasis on sequential activities
Pre-defined detailed deliverables
Separation of users from IT specialists
Criticised for delivering systems that are:
 Over budget
 Over schedule
 Not what users need
 Exacerbate the ‘culture gap’
DSDM 1997 (Dynamic Systems Development Method - Standard
 Active user involvement
 DSDM teams must be empowered to make decisions
 Focus on frequent delivery of products
 Fitness for business purpose is the essential criteria for acceptance of deliverables
 Iterative & incremental development necessary to converge on an accurate business
solution
 Changes during development are reversible
 Requirements are baselined at a high level
 Testing integrated throughout the life cycle
 A collaborative & co-operative approach between all stakeholders is essential
RAD Potential Strengths:










Better Client-Developer communication & collaboration
Encouraging change of mind by clients allowing systems to evolve through changing
business environment/client perspective
Encouraging an effective learning environment for both developers & users
Increasing client confidence
Facilitating earlier & more testing
Providing the potential for cost reductions
Reducing the deadline effect
Facilitating better interfaces
Reducing risk
Motivating users and developers
Potential Weaknesses:
 Management problems
 Lack of control
 Raised user expectations
 Selecting & motivating the right users & developers
 Not viewing RAD as a fundamental change in approach, attitude & philosophy
Notes from Avison & Fitzgerald (1995)
What is prototyping?
“A prototype is an approximation of a type that exhibits the essential features of the final
version of that type”
‘uses system development tools in bid to improve requirements analysis’
“what the users wants is what they get” Avison & Fitzgerald (1994)
prototyping can be seen as improved form of system investigation & analysis & an aid to
design
Why use prototyping?

It addresses some of the problems of traditional Systems Analysis
(ie. users only saw IS’s at implementation stage)
 Is a response to the user dissatisfaction found when using the trad. Approach to IS
dev.
Allows Analyst to show users something:
 Tangible
 Inputs
 Intermediary stages
 Outputs
Before committing user to new design
When to use prototyping?
Prototyping can be seen as improved form of systems investigation & analysis & an aid
to design
Particularly useful when:
 The application area is not well defined
 The organisation is not familiar with the technical h/ware, s/ware,
communication, design etc.
 The communications between analysts & users are not good
 The cost of rejection by users would be v. high & it is essential to ensure that the
final version has got users’ needs right
 There is a requirement to assess the impact of prospective IS’s
When to use prototyping?
 By analysts to examine areas where they are unsure of user requirements
or
 Where they are unsure how to build the system
 Some analysts recommend that only the most critical aspects of a new system
should be prototyped
Prototyping could be used as a basis for a methodology of system development in
the organisation – this may have:
 An analysis phase
(designed to understand the present system & suggest the functional requirements
of an alternative system)
 A prototyping phase (to construct a prototype for evaluation by users)
 A set of evaluation & prototype modification stages
 A phase to design & develop the target system using the prototype as part of the
spec.
Many prototypes are intended to be discarded – not designed to be used as operational
systems as they are likely to be:
 Inefficient
 Incomplete
 Poorly documented
 Unsuitable for integration with other operational systems
 Incapable of holding the no. of records necessary
 Inadequate, being designed for one type of user only
Here they are used as a development tool – a learning vehicle
An alternative approach – to use final prototype as the basis for the operational system –
where IS ‘evolves’ by an iterative process.
“one of the necessary components of successful prototyping is management and control
so as to ensure that compromises are not made and the process of repeated iteration does
not go on too long” (Avison & Wilson, 1991)
IS may be developed in stages:
 At each stage the missing components are those which give the poorest ratio of
benefits over costs
Problems:
 Users may question the long time required to develop an operational system –
when little time taken to produce prototype
 Users may argue that time, effort, money used to develop a prototype is ‘wasted’
 Analysts tempted to move quickly on to development phase before sufficient
analysis carried out
Prototyping
 Was expensive – but changed with availability of software tools
 Encourages a degree of user participation
 Enable users & analysts to ‘act out’ the future system
Rapid Application Development (RAD)
The goal is to speed up the development process
Martin, (1991) suggests RAD is an example of an approach that uses prototyping
as part of an overall methodology
RAD – based on:
 Evolutionary, prototyping approach
 Enabled by CASE tools & system repositories
Why RAD?
 As a need to develop IS’s more quickly
 Driven by ‘changing business requirements’
 General environment of business seen as competitive
 More customer focused & operating in international context
 Business environment characterised by continuous change
 IS’s in organisation – need to be created & amended quickly to support
these changes
 RAD – a combination of techniques & tools
 Not based on trad. Life cycle – but adopts evolutionary/prototyping
approach
 Focuses on identifying important users & involving them in workshops at
early development stage
 Focuses on obtaining commitment from the business users
 Requires CASE tool with sophisticated repository
RAD has 4 phases:
 Requirements planning
 User design
 Construction
 Cutover
Requirements – 2 techniques
 JRP Joint requirements planning (identify high level mgmt. requirements
of system at ‘strategic level’
Participants – senior managers
(vision & understanding of overall objectives of system – how can contribute to
goals & strategy of organisation)
Workshops
 To identify priorities
 To eliminate unnecessary functions
Joint application design (JAD)
 Main technique of user design phase (analysis & design)
 User design achieved by right environment, use of good prototyping tools
Prototyping tools allow quick exploration of processes:
 Interfaces
 Reports


Screens
Dialogues
User design dev. Using 4 diagramming techniques:
 entity modelling:
 Functional decomposition
 DFD’s
 Action diagrams
RAD
 uses automated tools
 reusable parts
 small teams – user involvement
Therefore IS’s implemented at:
 lower cost
 higher quality
 increased speed
 meeting needs of business
 leading to lower maintenance costs
‘the emphasis is on getting the requirements as correct as possible & to reflect the
business needs’
In UK – RAD users & suppliers group – formed consortium to define standards &
framework for RAD
‘Dynamic Systems Development Method’ (DSDM)
CASE tools:
 check internal consistency
 enable speedy, accurate & effective transfer of results
Cutover:
 comprehensive testing
 users are trained
 organisational changes implied by system are implemented
 running old & new in parallel
RAD adopts evolutionary or timebox approach to development & implementation
‘timebox’ approach contrasts with trad. Approach where every conceivable requirement
is implemented together & resulting complexity often causes long delays in
implementation
Download