Rapid Application Development

1. Rapid Application Development • RAD is a complete methodology covering systems development from business requirements through to ongoing development ( often incorectly called maintenance) (Bates & Stephens, 95)

2. RAD • Origins, IBM (Morris) in the 1970’s • Martin (1990) • Goals of RAD • High quality systems • “ Meet the business requirements as effectively as possible at the time the system comes into operation” (Martin, 1991) • Fast development and delivery • Low costs • A RAD project must be delivered in anything from 2-6 months • Project too large – incremental development of working parts of the system

3. RAD • Low cost • An aim of all development to be cost effective • An organisation may be willing to pay more if it gets its required system in a shorter period of time • Lower cost goals are acheivable

4. RAD • Quality of systems must still be maintained • There must be effective project management, up to date documentation, testing quality assurance, requirements specification, designs, appropriate maintainability, reuse.

5. RAD RAD approach is more applicable to many organisations for the following reasons: (Bates & Stephens, 95) • Business operates in an increasingly competitive market place – the right systems at the right time provide an essential competitive edge • Business organisations are dynamic and evolving – requirements may change as the system is being built, rendering a frozen spec approach redundant

6. RAD • IT is now viewed as a cost centre as opposed to a resource – systems delivered early can start saving or earning money sooner • Systems operate in the social and political environment of the organisation – if the system has been jointly developed by the users then it is more likely to be accepted

7. RAD The structure of projects change when RAD is applied. The main changes may be summarised as: • Reduced time scales for deriving business requirements including the use of JAD workshops • Iterative development in conjunction with users involving prototyping and frequent delivery of working products

8. RAD • In comparison to the traditional model – Different philisophical outlook • After a feasibility study and appropriate research into the application, A Joint Application Design workshop is held.

9. RAD • Key users, the client and developers produce system scope and business requirements under the direction of a facilitator • JAD workshop – must come up with the business requirements, fully documented, typically at the end of 3 to 5 working days • As much to do with obtaining a common purpose from individuals as obtaining system requirements and business objectives

10. Management of RAD Potential Strengths • Enables better client-developer communication and collaboration • Encouraging change of mind by clients allowing systems to evolve through changing business environment or client perspective

11. Management of RAD • Encouraging an effective learning environment for both developers and users • Increasing client confidence • Facilitating earlier and more testing • Providing the potential for cost reductions • Reducing the deadline effect • Facilitating better interfaces

12. Management of RAD • Reducing risk • Motivating users and developers

13. Management of RAD Potential Weaknesses • Lack of control • Raised user expectations • Selecting and motivating the right users and developers • version control