when it comes time to design it, test it, use it, or enhance it. There are precious few artifacts generated during the process–outside of the what is directly in the visual programming tool. Design decisions are made on the fly and will not have been justified or particularly well thought out. Testing must be carried out in an ad hoc fashion; there is nothing on which to base test cases. And pity the poor soul that must enhance the application if it ever is put into production.
On the positive side of the ledger, RAD mandates that users are involved early and often. Most RAD efforts have an aggressive attitude towards the rapid creation of value. People involved in RAD efforts can turn code revisions around in a matter of hours or days. They keep users interested longer because the users see their ideas come to life in front of their eyes. Not to be forgotten are the visual programming tools which make the RAD approach possible. All of these are very positive aspects and must be brought forward.
The challenge is to augment the positive aspects of the RAD approach with the "tweaks" mentioned earlier. Applications built using this augmented RAD approach will be:
- built quickly with few defects,
- implemented smoothly with minimal training,
- supported effectively and efficiently,
- accepted by users,
- enhanced at a reasonable cost.
You can augment the RAD approach by understanding what categories of information are important enough to pay attention to, by including enough analysts in the prototyping sessions to recognize when information in those categories comes up, and by providing consistent models to be used in structuring that information.
The categories of valuable analysis information which need to be indentified during the prototyping sessions include:
Þ business context;
Þ entities and their attributes;
Þ changes to key entities over time;
Þ users and roles;
Þ user goals;
Þ system tasks.
To actually capture and structure the information, the RAD approach must be changed. Additional analysts should be present in the prototyping sessions with the responsibility for capturing information in one or more of these categories as it comes up in the sessions.
There are modeling techniques that can be effectively used by analysts in these sessions to capture the information. This will not interrupt the flow of the sessions–the analysts are silent information gatherers. They become active members of the process, however, between sessions where they work with each other and the wizard to add formality and consistency across the models and to generate questions to be asked of the users in follow-up sessions. As more sessions are held, the models containing structured useful analytical information become more and more complete.
When this process is put into place to capture this information, there will not be a decrease in the speed of which applications get built. Initially, there will be a higher run rate for the development effort. This will translate into a decrease in overall cost for the development effort as it will end sooner and an increase in the benefits of the application as users will be presented with an application that meets their needs immediately without defects.
A RAD approach can be made more reliable by using techniques which allow for the systematic capture of detailed information surrounding the application that is to be built. These methods create artifacts which allow for demonstrating a detailed understanding of what the application must do, tracing of why certain paths were chosen over another and testing of the application once coded. Finally, the next wizard that comes along will have a fair shake in