Custom Software Development, Web Design, Database Programming RAD Methodology

Services - RAD Methodology  

The graphic below illustrates a typical chain of RAD process events.  Note that the left side dotted line from 'Object Creation' through 'Return to Brainstorm, Requirements, Analysis' is optional.  If the system designers are well versed on the system requirements then the first RAD deliveries may not have to be redesigned.

If you are looking to hire a software development company right now get our critical success strategies guide for hiring a custom software or web development company.

Image Courtesy of James P. Greichen

RAD is the process of creating a new software system by involving the user community in all phases of the system creation.  It implies a user driven design.  Deliveries of the system are broken into several milestones, each containing more system components than the previous milestone delivery.  The first delivery is usually a prototype of the complete system to include system flow from form to form to report, etc.  All appropriate users have a chance to review each delivery before work commences on the remainder of the system.  User input to changes is a core requirement to the success of this methodology.  RAD facilitates early user acceptance, and ensures that all important users of the system have input to system functionality before its final delivery.  RAD development is an important tool in the risk management of a custom software system.

RAD is a manifestation of Vilfred Pareto's law known as the 80 - 20 Rule.  It states that 80% of XX is caused by 20% of YY.  More specifically, 80% of the costs of a complete system are due to 20% of the features included in the system.  Conversely, 20% of the system costs are due to 80% of the system features.  RAD methodology allows the most important 80% of the system features to rise to the top of the list and be integrated into the system - at a cost of 20% of the complete system.

RAD lends itself to an hourly billing, however, it can also be used in a fixed cost environment if the customer agrees to a limited amount of RAD deliveries and repetitions (hours).

The following further describes the RAD Methodology:

• It is important that a contract that is agreeable and beneficial to both sides is signed before any work begins.  If the project does not present a 'Win - Win' situation for both parties, then it is not in the best interests of at least one party to proceed further.
• Once the contract is signed, the Brainstorm, Requirements, and Analysis steps may be repeated until enough information is known to create a prototype. 
• The prototypes are mock ups at this stage, and may be completely thrown out if necessary.  Code is not deliverable quality.  The prototypes will usually change significantly after user feedback, and the impact of these changes are minimized if the prototypes are bare bones - for visual and navigational demonstration only.
• The Object Creation and User Review steps can be repeated multiple times until the system is correct and accepted by the user community.  Objects might include data entry forms, high profile management reports, engineer reports, etc.  In order to meet tighter schedules, it is important for the group of users that are reviewing the prototypes to commit to timely feedback.  In this methodology, the project schedule is often driven by the time taken by the user community to review deliveries.
• Optionally, if the User Review step results in fundamental changes in the direction of the system, the Brainstorm, Requirements, and Analysis steps can be repeated as depicted in the diagram above.
• Once all of the above steps are completed to the acceptance of the user community, the system code is finalized in preparation for final delivery.
• The system is delivered (with all documentation ), installed, and configured.   Users are trained, and the system moves into maintenance mode.

Advantages of the RAD methodology:

1. Flexible and adaptable to changes.
2. Prototyping applications gives users a tangible description from which to judge whether critical system requirements are being met by the system.  Report output can be compared with existing reports.  Data entry forms can be reviewed for completeness of all fields, navigation, data access (drop down lists,checkboxes, radio buttons, etc.).
3. RAD generally incorporates short development cycles - users see the RAD product quickly.
4. RAD involves user participation thereby increasing chances of early user community acceptance.
5. RAD realizes an overall reduction in project risk.
6. Pareto's 80 - 20 Rule usually results in reducing the costs to create a custom system.

Disadvantages of RAD methodology:

1. Unknown cost of product.  As mentioned above, this problem can be alleviated by the customer agreeing to a limited amount of rework in the RAD process.
2. It may be difficult for many important users to commit the time required for success of the RAD process.