Background to RAD

1
Background to RAD
2
RAD

• Rapid fast, urgent.
• Application a system with a purpose.
• Development a process of creating, growing and
  maturing.
• RAD a process of creating a purposeful system
  quickly.
• RAD is often described as an agile approach to
  creating software.

3
Antithesis of RAD

• Slow?
• More expensive?
• Better Quality?
• Such approaches are often described as
  heavyweight or plan-driven.

4
Lets look at Systems now...

• System - a set of interacting elements
  responding to inputs to produce outputs
• Computer systems are built by (developers) and
  operated by (users) human beings.
• They help us achieve business objectives, e.g.
• increase market share.
• improve cash flow.
• reduce costs.
• increase profitability.
• However, after sixty years of system development,
  there are countless failed projects.

5
Example of System FailureThe London Ambulance
Fiasco

• In 1992, the London Ambulance Service introduced
  the Computer Aided Dispatch System (LASCAD).
• System main functions
• call taking, handling incident details including
  locations.
• Resource (ambulances) identification and
  mobilisation.
• Ambulance resource management, positioning
  ambulances to minimize response time.

6
Cont. The London Ambulance Fiasco

• The system failure on 26th Oct. 1992 led to
• Massive delays in responding to incidents, with
  delays of up to 11 hours.
• There were media reports that the system failure
  to promptly respond led to the death of up to 30
  patients.

7
Cont. The London Ambulance Fiasco

• According to the report of the London Ambulance
  Service Inquiry, the causes of the system failure
  were due to
• System was relying on inaccurate data to allocate
  resources to incidents,
• poor coverage and congestion of radio system.
• Software resource allocation errors.
• Staff frustration and system misuse.

8
Cont. The London Ambulance Fiasco

• System was NOT
• complete
• well designed
• properly deployed and tuned.
• fully tested.
• Staff were not properly trained to use the system.

9
Application n. a system with a purpose.

• A purpose implies that the system satisfies some
  Requirements.
• Requirements are very important in developing
  systems.
• People specify, agree and change requirements.

10
What are Requirements?

• My car must have a steering wheel.
• My vacuum should have a beater bar.
• My drawing package could have a facility to
  filter out all pictures with colour brown in
  them.
• So requirements are usually textual descriptions
  of what you need or want.

11
Types of Requirement

• There are many types
• Functional Requirements, define the internal
  working of the system.
• Non-Functional Requirements, specify overall
  characteristics such as cost and reliability.
• And within each of these you might see
• Domain Specific Requirements
• You might even see the terms
• User Requirements
• System Requirements
• Qualitative Requirements

12
Problems with Requirements

• Imprecise or ambiguous natural language.
• Developers make erroneous assumptions.
• Requirements change and lists grow.
• Qualitative requirements are difficult to test
• My idea of secure is different from yours.