As with many new concepts, Rapid Application Development, or RAD, can seem to take on qualities of magic. One can sit with users and construct an application in front of their eyes to directly meet their needs. Seems too good to be true, and it is. Building good software applications requires discipline and tedious hard work. Visual programming tools are making software development efforts less tedious, but they are not a substitute for the hard work and discipline required to build high quality software.
As with many new concepts, Rapid Application Development, or RAD, can seem to take on qualities of magic. One can sit with users and construct an application in front of their eyes to directly meet their needs. Seems too good to be true, and it is. Building good software applications requires discipline and tedious hard work. Visual programming tools are making software development efforts less tedious, but they are not a substitute for the hard work and discipline required to build high quality software.
A RAD approach places users in prototyping sessions with developers who are well schooled in a visual programming tool such as Visual Basic, Window Builder Pro, Powerbuilder, Lotus Notes, or Java. Incredible amounts of important analysis information are generated through this approach as the developer concentrates on capturing the information related to the user interface. Unfortunately, most of the other valuable analysis information "plops" on the floor of the conference room and is not captured. It may be discussed later during the development effort, perhaps multiple times, or be forgotten until it is too late.
In this article, I describe a straightforward change to the RAD approach which will allow for the capture of that information which is typically lost during the RAD process. To "tweak" the RAD approach, you must:
- train analysts to recognize what is important analysis information;
- put them in a position where they can see the information when it is generated;
- use models to capture important analysis information.
The capture of that information will not take the rapid out of RAD; in fact, it should speed up the development effort–when the full life cycle of the application is taken into account. The trade-off is a higher cost of the development effort because more people are involved. They will ensure that information is used as a basis for building a shared and complete understanding of what the application must do and for the designing, building, testing, and enhancing of the application to meet those expectations.
The RAD approach is generally an iterative one. A project utilizing the RAD approach has a limited amount of time in which to meet its objectives. The project is rapidly formed by finding a tool wizard (someone well versed in the visual development tool of choice), teaming the wizard with a couple of users and giving them a few words of encouragement along with a general idea of the what the scope of the effort is. Thereafter the project iterates between:
- meetings wherein the users indicate how they want their application to look and the wizard paints it. The users react to what the wizard paints and she tweaks the application to the best of her ability. In later meetings, the wizard will have some questions to ask regarding capabilities of the application not directly visible from the user interface.
- time between meetings when the wizard goes away to begin to "fill-in" the application. This includes polishing the user interface with changes not done in front of the users, talking with the data base designer or data management to find data required, and determining how the data must be transformed as it moves between the interface the data sources.
This process is repeated until there is some consensus that everything has been covered–or the allotted time runs out.
Shortcuts are inherent in this process. These short cuts allow "impossible" immediate deadlines to be met (there is an element of short term thinking inherent in any RAD effort, but that is topic for another time...). It is these very same shortcuts that are the death knell for the application 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[1] 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 figuring out exactly what the application does.
[1] These "entities" are those same things referred to as “objects” by naïve object modelers or "entities" by information engineer–but limited only to the problem domain, design objects are not included here.
