Rapid Application Development (RAD)

WHAT IS IT, WHEN IS IT DEPLOYED AND WHAT ARE THE PROS AND CONS?

WHAT IS RAD?

Rapid Application Development is a software development methodology strategy in which software is developed in a rapid way so that the software application is prototyped and tested quickly through its development to arrive at a final product.

RAD is one of the model types which can be used within the broad guidelines of the software development life cycle (SDLC). Other models which can be used in this way include the Waterfall model, the Spiral method, the Iterative and Incremental method etc.

The SDLC is the framework, used since the 1970s, to describe the progress of a software development project from the planning stage to deployment. The stages in the SDLC are:-

• Gathering business requirements and analysis of data
• System and software design to meet the needs of required specifications identified in 1. Also in this phase the test strategy is identified.
• The work is implemented by dividing into modules and coding is begun.
• The coded modules are tested to ensure they meet the business requirements, and all types of functional testing are completed.
• The software is delivered to the customer for use. Any initial changes required are made and a final delivery is completed.
• The customer begins to use the software in its final form in a business situation. If any problems arise at this stage the developers intervene to maintain the product.

EVOLUTION OF RAD

Software development methodology didn’t emerge until the 1960s and a preordained plan-driven model, based on engineering models, appeared to be the logical way to go. The SDLC had its earliest incarnation as the Structured Systems Analysis and Design Method (SSADM), which was the first formalised methodology for building information systems. This evolved through the 1980s as a waterfall process. However, there began to be general dissatisfaction with the accepted methods of software development where product specifications were defined at the outset, but were no longer valid by the time of product release. The beginnings of RAD, as a concept, was identified by James Martin.

After studying physics at Oxford James Martin began working for IBM in 1959, and soon after this started to write the first of his many books on IT and computing. His publications eventually totalled over 100 and many of these became standard texts for teaching computer programming and systems design.

Martin collaborated with colleagues to develop a new approach, called Rapid Iterative Production Prototyping (RIPP), which subsequently led to his book Rapid Application Development, published in 1991.

JAMES MARTIN MODEL

The James Martin model has 4 stages and relies on speed of production:-

1. Requirements and Planning stage

Decisions on business needs, scope of project, constraints and application requirements are made jointly by users, designers and developers.

2. User design stage

Users, together with systems analysts, work together to model and make prototypes for all systems processes, inputs and outputs. They use a combination of Joint Application Development (JAD) techniques and Computer Aided Software Engineering (CASE) tools to marry user needs with working models.

This is a continuous (iterative) interactive process which allows users to modify and approve a working model that satisfies them.

3. Construction stage

Concentrates on programme and application development work, coding, integration and testing. Users continue to have an input, providing suggested changes and improvements as development proceeds. The construction stage is a rapid process and relies on iteration to modify the project as new components and alterations are added.

4. Cutover stage

This embraces the installation of the system, user acceptance testing and user training.

The James Martin model is a compressed version of the traditional SDLC. It provides a more rapid route to a fully developed, operational, product, and, with the advantage of user input, also makes it a more accurate reflection of the user's needs.

RAD, as it is used today as a method of software development (although it can also be used to develop hardware), depends on rapid prototyping and iterative delivery. It falls, with other techniques, under the sphere of influence of the agile philosophy.

RAD is a type of incremental model in which the individual components are developed in parallel. This is done within a time box environment with the developments then being assembled as a working prototype. The prototype is then user tested and quickly delivered to the customer so that immediate feedback on the delivery, and how it meets customer requirements, can be relayed back to the development team. An iterative process then engages until a satisfactory result is produced.

WHEN IS RAD DEPLOYED?

• When the project can be modularised
• When there is the availability of user input in order to help produce prototypes
• When the budget can allow for highly skilled engineers, a high volume of designer input for modelling and the cost of automated code generating tools
• When the presence of domain expertise is highly likely
• When the customer is committed to change and can accommodate targeted prototypes and incremental delivery within small time frames

PROS AND CONS OF RAD

PROS

• Rapid delivery because the development time is reduced
• Improved productivity because fewer people mean lower costs
• The use of timeboxing controls the cost and keeps the project to schedule
• Customer involvement reduces the problem of the customer not getting what they want
• Continuous and rapid user feedback gives invaluable evaluation information
• WYSIWYG from documentation to code
• Increases the usability of components
• Changing requirements can be incorporated
• Reduced development time
• Continuous integration means reduced integration issues
• Overall progress can be easily measured because of the frequency of delivery of components and prototypes. This gives greater control over budget and schedules

CONS

• Only of use in a modularised and component based environment
• Needs a highly skilled team of engineers, designers, developers and domain expertise
• Needs a budget sufficient for modelling and automated code generation
• Needs constant user involvement
• Can be difficult to mesh within large scale projects