This competitive world is giving rise to a demanding market where delivery time for anything should be as little as possible. From pizzas to software products, everyone is highlighting shorter delivery time as there USP. In such a scenario Rapid Application Development (RAD) has appeared as a winning solution for this demand. RAD is a software methodology that involves iterative development, quick construction of prototypes, and the use of Computer-aided software engineering (CASE) tools. And as the name indicates, RAD technique allows really “Rapid” application development, with development time limited to 30 or maximum 90 days. However, rapid application development approach is concerned with few compromises in usability, features, and/or execution speed.
Let’s have an idea about the origin of this effective methodology. Beginning with the creative ideas of Barry Boehm and Scott Shultz, James Martin developed the Rapid Application Development process in the 1980s at IBM. This valuable process was finally formalized in 1991 when James Martin published a book explaining RAD.
As an overview, application development means developing programming applications which vary from general programming in the sense that it possesses a higher level of liability, including for requirement capturing and testing. In 1970’s, Rapid Application Development appeared as an awful response to non-agile processes, such as the Waterfall model. Software developers faced the time problem with previous methodologies as the applications took so long to build that the requirement specifications changed by the time the system was complete. Thus, such methodologies frequently resulted in unusable systems.
RAD methodology is in the reach of almost everybody as the code generators, visual tools like VB, Visual C++ and CASE tools like Rational Rose are based on RAD technique only. If you design your application with Rational Rose, code can be automatically generated in languages like C++, VC++ or VB. For a simple example, if you have used tools like MS FrontPage then it’s again a RAD tool. What you see while working with MS FrontPage? You just design your web-page layout and its content and HTML code will be automatically generated.
You can find many methods of RAD that can be applied in software construction. Many commercial or free functional libraries are available from where you can seek some functionality of your application. The only thing you need to do is to simply link them correctly to your application. Many times, you may get a re-usable code that can be used with no or little modifications.
Now let’s discuss something about code. Most of the code generators are supported by template approach in which some template parameters are substituted with the inputs given by you. A good code generator should take least number of inputs. However, the inputs should be meaningful and given in well-defined sequence. Another significant example of RAD can be taken as Visual Integrated Development Environments (IDE), which allows visual construction of application as a result of which equivalent code will be automatically generated along with compilation, execution and version management facilities. As code can be reused in RAD so object-oriented programming becomes another candidate for RAD activities.
The different tools of RAD methodology are:
- Database Rapid Application Development Tools
- Cross-Platform Rapid Application Development Tools
- Web Based Rapid Application Development Tools
- Desktop Rapid Application Development Tools
- Embedded Control Rapid Application Development Tools
- Components based on Rapid Application Development paradigm
Thus, we see that RAD offers many advantages which can be summed up as follows:
- Improved speed of development through rapid prototyping
- Better end-user utility
- High emphasis on simplicity and usability of GUI design
- Lower Cost
- Automatically generated code thus improving quality & reducing time
- NO Testing Efforts
Well, by this time, a thought comes to mind that even after possessing several advantages, why this methodology is not always used by software developers? It’s because of the couple of negatives associated with this methodology. These are:
- Reduced Scalability
- Reduced features
- As it takes very little time & tasks are automated, so, confidence in product is usually low for risky and mission-critical applications.
This is the reason, why Rapid Application Development methodology is not used for complex and high-risk applications where requirements are uncertain & critical. Although it is best suitable for well defined & low-risk applications.
Source by Anne Catherine