Many developers think of rapid application development (RAD) as a way to deliver projects without having to spend time on planning or analysis. This is not the case at all. RAD is a development methodology—different from the waterfall approach but a methodology nonetheless. At one time, RAD was brand new and sexy, but it has been utilized successfully, and unsuccessfully, for a number of years now.
RAD features these overriding characteristics:
- The focus is on delivering projects in small pieces. If you have a large project, you need to look at ways to break it into smaller projects, each of which can be planned and delivered individually. With a series of smaller projects, you can deliver each one more quickly and in a less structured manner.
- Deliverables, including the final solution, are created using a repeating process of analysis, design, construction, and testing. Prototypes are created early and evolved to include more detail over time.
- RAD emphasizes reuse. This includes the reuse of code, processes, templates, and tools. It is usually faster to assemble prebuilt components than to build everything from scratch.
With those characteristics in mind, let’s take a look at the RAD life cycle.
Just as with the waterfall methodology, you need to plan the work first. (And just as with the waterfall method, many people consider planning to be a part of the project management process). The key deliverables from this phase are a Project Definition that describes and defines the project, Project Management Procedures that describe the processes for managing issues, scope, risk, communication, quality, etc., and a Workplan that describes the activities needed to complete the project. Because the project is smaller, less time is required to plan the work.
You still need to capture the business requirements, but now there is a twist. Instead of spending the time to gather a precise set of detailed requirements, you first gather the requirements at a high level. Focus on the main features and functions to be delivered, as well as the overall batch and online processes. The requirements do not necessarily need to be formally approved by the customer, since the RAD approach allows them to change over time. However, it is still a good idea to make sure that you understand the requirements.
There is usually no need to make a build-or-buy decision. By utilizing the RAD approach, you should have already determined that the solution most likely would be assembled/built.
The first time through the analysis phase, you should still look ahead in the project to plan the approach for some of the later activities. Because a RAD project is smaller, you can probably bypass the high-level strategy documents and focus directly on the lower-level documents such as the Testing Plan, Training Plan, and Implementation Plan. If the project is small enough, the plans can be bypassed as well, with the lower-level activities discussed with the customer and placed directly into the Workplan.
Utilize the requirements you received in the previous step to build a high-level prototype of the application. The first time through, this may just be a series of screens that show how a business transaction is processed. There may not be any database calls or business logic programmed behind the screen shells. During this first pass, basic decisions also need to be made in terms of the technology and tools to utilize, since the prototype may lead directly to the solution. Remember that you want to maximize the amount of content being reused and keep new construction to a minimum.
Repeat analysis and prototyping as necessary
When you’ve completed the initial prototype, you can use it to gather additional, more detailed business requirements from the customer. The thought here is that customers can better give requirements once they can start to see how the solution looks and feels. Once you get the modified set of requirements, you update the prototype to reflect the new set of requirements. When that prototype is completed, you take it back to the customer again to revalidate requirements.
Conclusion of prototyping
The project manager and customer need to agree on a fixed number of prototyping iterations or else this cyclical process could go on forever. Usually, three iterations is a good number. At that point, you will have two approaches to finish the project. First, if you developed the prototypes with the final solution in mind, you need to finish the design, programming, and testing of the solution using the prototype as the starting point. In fact, depending on how much business logic you put into the last prototype, you may find that your solution is close to being completed.
The other option is to throw away the prototype and begin developing the production application from scratch. If you take this approach, it is imperative that you don’t spend much effort on the prototype itself.
In either case, the testing process still needs to be completed. The prototype may have taken you through unit and integration testing, but you still need to system test and gain user acceptance before the application can be implemented.
Normally, you do not prototype the implementation phase (although you may run a pilot test, which is different). So, the implementation phase proceeds similarly to the waterfall method.
Where does that leave us?
When you boil it all down, you notice that the typical development processes of analysis, design, coding, testing, and implementation are still visible in the RAD approach. However, the pieces are emphasized differently. There is less up-front time spent in analysis and design, and construction is performed much earlier. The analysis/design/construction process is then applied in mini-cycles a number of times until you get to an 80/20 solution. At that point, final construction and testing is completed, and the solution is implemented.
Coming up: Waterfall vs. RAD
Although I believe all projects can be executed with the waterfall methodology, I do not believe all projects are candidates for the RAD approach. In the final column in this series, I will discuss the characteristics that make a project better suited for one approach or the other.
Project management veteran Tom Mochal is director of internal development at a software company in Atlanta. Most recently, he worked for the Coca-Cola Company, where he was responsible for deploying, training, and coaching the IS division on project management and life-cycle skills. He's also worked for Eastman Kodak and Cap Gemini America and has developed a project management methodology called TenStep.