似乎每家生产软件开放工具或平台的供应商都宣称他们的工具或平台可以用来进行“快速应用程序开发（RAD）”，但是却很少用证据来支持这一说法。
什么是 RAD？
除了是一种市场称谓之外，RAD 还可以用来描述在60到90天之内设计和开发的应用程序。James Martin 于上个世纪80年代中期在Dupont工作时提出了这个概念。就是在那里他和Scott Shultz 使用一个他们称之为快速交互性生产原型的方法学形式化地提出了一个开发应用程序的系统，这种原型使用流程图来设计程序和应用程序。
Martin 被认为是计算机辅助设计之父，并且他最初的成果已经成长、增大和扩展为我们目前所知道的设计准则 RAD。经过多年的发展，RAD 已经成长为包括很多用于定义 RAD 项目的基本原则。
首先，RAD 项目使用原型来刻画特征。RAD 原型帮助我们快速步入设计过程并演示应用程序的观感，并减少为确定特性和功能而从用户那里收集需求的时间。
RAD 的概念是，通过一组来自用户的基本需求，开发人员通常可以在工作室环境下快速地构建一个原型，用户可以与这个原型交互并建议特性、功能增强等，而这个原型则作为联合需求设计（JRD，joint requirements planning）或联合应用程序开发（JRD，joint application development）过程的一部分。所以任何被吹捧为 RAD 工具的开发工具或开发平台应该能够方便地从一个 JRD 工作室收集用户需求，并应该能够快速地创建能够在 JAD 工作室中供用户查看和修改的应用程序原型。
一个好的 RAD 工具还应该为开发人员提供使用基于组件的架构来快速添加和删除特性的工具，而添加和删除特性要在不须要大量重新编写代码的情况下完成。除了在 RAD 项目的过程中更改用户需求之外，多数项目是“有时间限制的”，即为项目完成设置了一个时间期限。在这个时间期限内有任何不能交付的特性或功能都应该被删除或推迟到将来的发布中。
使用 RAD 方法创建应用程序的第二个特点是可能同时有很多开发人员正在同一个应用程序上工作，并且这些开发人员能够在他们的团队中扮演很多角色。例如，可能有一个开发人员已经为正在讨论的应用程序创建了架构，并设计了用户界面和后台代码。而同一个资源可能还在被用于开发成测试计划，用于测试应用程序，书写文档，以及最终培训用户。在更正式的项目中，这些角色可以在多种资源中分配。在一个 RAD 项目中，时间和资源限制通常意味着这些（或更多）角色通常必须由单个开发人员所担任。对于支持 RAD 这一方面的 IDE，它必须适应不同的角色；相反，开发人员必须担任和支持这些角色中的一个。
除了支持团队中的不同角色外，RAD 工具还必须能够支持使用第三方组件来交付用户需求。在构建与购买的争论中，开发人员必须能够购买他们没有时间去构建或不倾向于自己构建的组件。例如，如果一个开发人员正为一个应用程序进行编码和界面设计两种工作，那么他必须能够集成那些可以减少每个任务所需时间的组件（比如代码库、UI 组件等）。
最后也是最重要的一点是，对使用 RAD 方法创建的应用程序的最后检验是看这些应用程序是否符合特定的商业用途。在使用严格意义上的软件开发周期（SDLC，software development lifecycle）创建应用程序的一般阶段中，在这个周期中有很多可交付品（deliverable）必须交付，包括正式的访谈、详细的设计文档、与现有系统审的语义映射、流程文档等。
在一个 RAD 项目中，在项目结束时首要的问题是“这个应用程序符合它被创建的商业过程吗？”如果答案是肯定的，那么项目就被认识是成功的。出于这一目的，RAD 工具应该提供以下能力，即能够快速创建能够解决即将到来的商业问题的应用程序。虽然有一些 SDLC 要素包括在 RAD 项目中，但这不是首要问题。例如，对于一个真正的 RAD 工具，生成过程流图或数据库方案的能力并不像交付商业过程所需的功能那么重要。
对五种 RAD 工具的测试
在查看不同的开发工具和开发平台来进行实地测试时，我们分析对比了典型的 RAD 项目元素，包括快速和简单数据录入窗体，以及绑定到后台的一个简单的数据库表。根据 RAD 方法学，我们使用每个工具构建了原型，标注出一个工具在哪些地方提供效率，哪些地方有待提高。我们还分析了 IDE 对RAD 设计原则以及所需任务适应性的特性和功能的支持。
