RAD is a complete methodology covering systems development from business requirements through to ongoing development ( often incorectly called maintenance) (Bates & Stephens, 95)
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
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
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.
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
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
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
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.
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
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
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
Reducing risk Motivating users and developers
Potential Weaknesses Lack of control Raised user expectations Selecting and motivating the right users and developers version control