Rapid application development (RAD, what is it? when to use it and when not use it?sorry dont no RAD is a recent revolution in software design. Programming languages such as Visual BASIC are RAD languages because they are so easy to just throw together a simple application. I use Visual BASIC 6, but Visual BASIC.NET is the most recent version of this language RAD is self explanitory. It allows you to creat what would be complex applications consuming alot of time to develope in a considerably short amount of time. For example, Visual Basic and C# can be considered RAD programming languages. They both allow you to creat Graphical User Interfaces without all the underlying mess of having to design the framework to make the GUI work. Using VB or C# you can easily great a windows from and add window form objects to it (buttons, text, etc...).
Generally RAD is used when you need something done relatively quickly or when there isn't a requirement for completely customized "windows look and feel". The biggest advantage of RAD is that almost all the dirty work is done for you. You have a large buffet of tools available. It's just a matter of putting them all together to produce what you want. Rapid Application Development (RAD) is a marketing buzzword that almost every software development tool uses, yet one that rarely applies. At a high level it is an Application Development technique that uses Prototypes, Iterative Customization, and CASE Tools.
Advantages and Disadvantages:
=============================
Speed and quality are the primary advantages of Rapid Application Development, while potentially reduced scalability and feature sets are the disadvantages.
Increased Speed:
----------------
As the name suggests, Rapid Application Development's primary advantage lies in an application's increased development speed and decreased time to delivery. The goal of delivering applications quickly is addressed through the use of Computer Aided Software Engineering or CASE tools, which focus on converting requirements to code as quickly as possible, as well as Time Boxing, in which features are pushed out to future releases in order to complete a feature light version quickly.
Increased Quality:
------------------
Increased quality is a primary focus of the Rapid Application Development methodology, but the term has a different meaning than is traditionally associated with Custom Application Development. Prior to RAD, and perhaps more intuitively, quality in development was both the degree to which an application conforms to specifications and a lack of defects once the application is delivered. According to RAD, quality is defined as both the degree to which a delivered application meets the needs of users as well as the degree to which a delivered system has low maintenance costs. Rapid Application Development attempts to deliver on quality through the heavy involving of users in the analysis and particularly the design stages.
Reduced Scalability:
--------------------
Because RAD focuses on development of a prototype that is iteratively developed into a full system, the delivered solution may lack the scalability of a solution that was designed as a full application from the start.
At Automated Architecture our Just-In-Time Application Generation methodology provides the benefits of Rapid Application Development while minimizing many of the disadvantage, such as reduced scalability, through the generation of an enterprise level "prototype" that provides as a starting point a scalable, efficient, and well designed application.
Reduced Features:
-----------------
Due to time boxing, where features are pushed off to later versions in favor of delivering an application in a short time frame, RAD may produce applications that are less full featured than traditionally developed applications. This concern should be addressed as soon as possible through clear communication with the client as to what will be delivered and when.
Appropriate RAD Projects:
=========================
Rapid Application Development is not appropriate for all projects. The methodology works best for projects where the scope is small or work can be broken down into manageable chunks. Along these lines project teams must also be small, preferably two to six people, and the team must have experience with all technologies that are to be used.
Business objectives will need to be well defined before the project can begin, so projects that use RAD should not have a broad or poorly defined scope. Furthermore, in order to keep the project within a short time frame, decisions must be able to be made quickly, so it imperative that there be very few client decision makers, preferably only one, and they must be clearly identified up front. Client decision makers need to understand and agree to a RAD approach and ideally should be willing to accept a product that is less full featured and/or be willing to accept higher development cost (due to the emphasis on purchasing reusable components over building them) in exchange for increases in speed.
Why use RAD?:
=============
1. BAD REASONS FOR USING RAD:
-----------------------------
a. to prevent cost overruns (RAD needs a team already disciplined in cost management)
2. to prevent runaway schedules (RAD needs a team already disciplined in time management)
2. GOOD REASONS FOR USING RAD
-----------------------------
a. to converge early toward a design acceptable to the customer and feasible for the developers
b. to limit a project's exposure to the forces of change
c. to save development time, possibly at the expense of economy or product quality |
