"Tweak" Your RAD Process for Positive Results

[article]
Summary:

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

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 24
Oct 12
Oct 15
Nov 09