CP3015 Rapid Application Development

1
CP3015 Rapid Application Development

• Research

2
Subjects to be covered

• Prototyping and RAD Definitions.
• Where are we now ?
• Managing RAD Areas of Current Research and
  Interest.
• Conclusions.

3
Prototyping

• a) Prototyping is the process of writing programs
  for the purpose of obtaining information prior to
  constructing a production version. (Balzer 1988)
• b) Incremental Development is the development of
  a system in a series of partial products
  (increments) throughout the project timescale.
• An increment is a self contained functional unit
  of software with all supporting material,
  including EVERYTHING.
• (Graham 1992)

4
Prototyping (contd)

• c) Evolutionary development. As above but perhaps
  not within a predefined framework? (Connell and
  Shafer 1989)

5
RAD

• So what actually is RAD?
• "RAD provides a framework for building and
  maintaining systems which meet tight time
  constraints through the use of incremental
  prototyping in a controlled project environment".
  (DSDM 1995)
• Are these definitions of any value?
• Do they say anything new?
• Have we really progressed?
• Will RAD solve anything?

6
Prototyping and RAD Where are we now?

• Current State of affairs VIEW 1.
• Lots of papers published on prototyping and to a
  lesser extent RAD. Usually saying how good it is.
• Plenty of descriptions of people using it in
  projects but little hard detail.
• Often an emphasis on its use in conjunction with
  a particular tool.
• (The above paraphrased from Mayhew and Worsley
  1992)
• So lots of progress in the area.

7
Prototyping and RAD Where are we now?

• Current State of affairs VIEW 1 (contd)
• Some good theoretical models available e.g DSDM
• Lots of tool support
• A good (fair?) understanding of what it is all
  about in the computing industry.
• New development techniques which emphasise
  prototyping and RAD (DSDM)

8
Prototyping and RAD Where are we now?

• Current State of affairs VIEW 2.
• (Paraphrased from Ince 1992)
• BUT one of the big problems that remain is the
  control and monitoring of the process.
• So how can the following be avoided
• Uncontrolled iteration
• Unbuildable systems.
• Wild cost over run and no estimation possible.
• RAD/Prototyping (micro or macro scale) NEEDS
  control!

9
Prototyping and RAD Where are we now?

• Current State of affairs VIEW 2 (contd)
• Applies to both throw-away and evolutionary
  methods
• Prototyping literature suggests that if
  prototyping is carried out early in the
  development it should reduce the problems
  associated with incomplete or poorly understood
  requirements.
• So potentially costly and time consuming
  corrections required at the end of a development
  should be minimised.
• This suggests that prototyping should REDUCE risk
  and uncertainty NOT increase it.

10
Prototyping and RAD Where are we now?

• Why does it remain unpopular?
• Particularly as there is evidence that it has
  been useful in certain areas.
• Positive evidence for the adoption of prototyping
  Butler Cox (1988)
• "Managing Contemporary system Development
  Methods
• Time and effort reductions of 50 (but upto 80).
• Easier to manage some projects (smaller teams,
  easier to allocate staff, better quality systems
  produced).

11
Disadvantages

• 80 of developers said that time and cost control
  were more difficult to manage.
• The most difficult problems were
• Control of Scope (70)
• Setting of milestones (50)
• Checking of progress (50)
• Estimation (30)
• User wants prototype as operational system
  (approx 20-25)
• I.e all the typical management problems (but
  these are all related to traditional methods?)

12
Disadvantages (contd)

• More compression of stages
• More overlap between stages
• More change to manage (typically 50 of
  functionality change, and upto 100 of interface
  changed)
• Design review now becoming the bottlenecks, not
  construction
• Higher user involvement (200 to 400 increase in
  user time) more systems delivered, therefore
  requiring more user time!!
• Will the construction of elite RAD teams (both
  users and developers) create problems in the work
  place?

13
Problems that Remain

• The identified problems that remain
• Research and Development should concentrate in
  these directions
• How do you monitor and control the process?
• How do you ensure that unfeasible systems are not
  produced?
• What is the relationship between RAD/prototyping
  and standards such as BS5750 and ISO 9000?
• How is the cost of RAD calculated?
• How do you reconcile the demands of RAD and QA
• How do you maintain a system which has been
  prototyped?
• It may appear that most of these are to do with
  management and QA. (Also paraphrased from Ince
  1992)

14
Other areas which currently are also topical

• Research is going into the development of
  specialist tools and prototyping.(This has
  already been addressed)
• RAD and CASE(Steigerwald, Luqi, and McDowell
  1990)
• RAD and Object Oriented Methods(Zucconi, Mack,
  and Williams 1990)
• RAD and Re-use(Burns 1991- tool developed to
  support TIW prototyping with re-use in mind.)

15
RAD Tools

• The tools are available?
• This is not a universal view
• A significant problem in adopting this approach
  (Prototyping) is cited by Neco, Tsai and Gordon
  (1989)
• "Lack of necessary software tools
• Despite the multiplicity of 4GL languages and
  application generators their capabilities and
  usability varies widely.
• Also a lack of standardisation between them leads
  to problems
• Authors state (optimistically?) that increasing
  standardisation and increasing comprehensives of
  languages will overcome this.

16
RAD Tools (contd)

• "The management of uncertainty in software
  development". (Luqi 1992)
• Methods to integrate prototyping (with tool
  support) to change the way that software is
  developed and maintained.
• Recognition that software specifications change
  over time in most instances.
• Hence specification validity needs to be assessed
  periodically.
• Initially use prototyping to validate the
  original specification\ requirement.
• Base production systems on the prototype.
• Verify the production system against the
  validated prototype.

17
RAD Tools (contd)

• It is suggested that maintainers should use the
  prototype to revalidate the system against a
  specification that will not remain static.
• As change is required the change is validated via
  the prototype to assess its impact in an attempt
  to make change more predictable and manageable.

18
Managing and Controlling RAD

• Bailey (Ince 1991) suggests that the reason that
  commercial developers are suspicious of
  evolutionary methods (such as prototyping/RAD) is
  because they are seen as anarchic.
• It seems that despite evidence pointing at
  advantages, developers are wary of expanding its
  use.

19
Managing and Controlling RAD (contd)

• The requirement is maybe for existing prototyping
  models of development to be adapted and modified
  so that
• Estimation of cost and resource requirement can
  be done accurately
• Accurate monitoring of progress can take place
  using formal control procedures
• Methods of optimising the move from one stage to
  the next can be developed
• The main principle behind these ideas is that
  effective control can only be maintained through
  formal procedures.

20
Managing and Controlling RAD (contd)

• In addition a method of controlling the feedback
  loop must be in place.
• This must ensure that change is related to
  business needs.
• Hence changes from users must be evaluated to
  ensure that they are adding to the needs of the
  business.
• (Advocated by Crinnion, J. Martin, J. Mayhew, P
  etc)
• Otherwise change and iteration WILL not be
  controlled.

21
Managing and Controlling RAD (contd)

• This approach typified by work such as Linkman
  and Walker (1991) who contend that only by
  formally controlling the s/w development process
  can s/w engineering be truly practised.
• By looking at RAD within software development in
  this manner we are considering using it as a
  process.
• This method of development is also discussed by
  Graham (1991a, 1991b), who defines "rapid
  development" as a set of managerial controls
  which are used to control prototyping.

22
Managing and Controlling RAD (contd)

• By setting goals and using the stages outlined
  above it should be able to control an iterative
  development (process) by constantly assessing the
  headway made against set targets.
• Quality Metrics to assess delivered systems are
  also essential!

23
Time Management

• Growing number of project managers resorting to
  RAD or time-box techniques.
• TIME driven management
• Typically the periods of action will be 6-10
  weeks.
• After that period the development stops, finished
  or not!
• Evaluation of the prototype takes place and based
  on that a further time box is set up to carry on.

24
Time Management

• When using RAD or timeboxing it is important that
  the tasks to be completed in the period should be
  well understood.
• The method must make this clear.

25
Risk Driven Management.

• Typified by Boehm's Spiral model of Software
  development. (1986).
• So a typical spiral cycle would be
• The objectives of the portion being evaluated
  (performance, function, change requirement)
• The alternative approaches to developing the
  product are assessed.
• Calculation of the constraints put on the
  development.
• After these have been worked out
• An evaluation of the risks associated with the
  next stage takes place.

26
Risk Driven Management.

• At this point an appropriate course of action is
  taken. (E.g Evolutionary development, step in
  waterfall, development of throw it away
  prototype.
• Finally each cycle is concluded with a review at
  which it is important to ascertain that all the
  parties are committed to the next stage in the
  spiral.

27
Some ideas from IEE Colloquium on s/w Prototyping
and Evolutionary Development.

• Some traditional methods have not addressed the
  ideas of incremental or accelerated development.
  (SSADM)
• They were set up to help build systems to support
  an area of business.
• Nowadays the evolutionary approach is towards
• Changing a business system to improve its
  performance.
• As the business changes so the systems must
  change with it.
• Traditional ideas of a fixed specification,
  monolithic development methods and "maintenance"
  phases are becoming questionable.
• (Crinnion 1992)

28
Some ideas from IEE Colloquium on s/w Prototyping
and Evolutionary Development.

• Development must converge.
• Short time scales 6-10 weeks.
• Time box approach, not cost and effort to
  deliver.
• Reviews to assess productiveness, not
  productivity.
• Productiveness linked to business goals
• Price driven, not cost driven
• Partnership contracts
• Software Development must become constraint
  driven.
• Users are no longer merely the developers
  customers.

29
Conclusions

• 1. Managing RAD/Prototyping An introduction?
• A lot of interest in the area. Questions remain
  over its actual use.
• 2. Areas of Current Research and Interest.
• Various areas active, determined by the
  perceived problems in prototyping.
• 3. Research into Tools and Prototyping
  Environments.
• Most work concerned with specification and
  requirements. Specialised languages/environments.

30
Conclusions

• 4. Management and Control.
• Current methods control development? This is
  perhaps a myth. Evidence suggests that there are
  still problems.
• 5. Suggestions on controlling prototyping and
  evolutionary development (iteration of any form).
  Theory.
• Putting control into prototyping more
  explicitly. Major changes in management and
  developer attitudes required.
• 6. Examples of work carried out with some
  suggestions on how it can be done. Practice.
• Not much evidence exists currently !