快速应用模型的正确方法：
RAD是直接连续的编程改进措施模型，该模型使用基于组件的开发方法强调紧凑的改进周期。如果确实知道并描述了必要性，并且任务程度是一个限制，则RAD周期可以使一个进步小组在紧凑的时间范围内制定一个完全实用的框架。
快速应用程序开发(RAD)的想法是，可以通过以下方式更快，更高质量地生产物品
- 利用研讨会或中心聚会进行社交活动的先决条件。
- 对计划进行原型制作和早期，反复的客户测试。
- 重新利用编程部分。
- 计划不紧不慢的计划，暗示计划增强了以下项目形式。
- 减少评论和其他聚会信件的显示。
RAD的不同时期如下：
- 业务建模–
业务能力之间的数据流的特征是解决以下问题，例如哪些信息驱动了业务周期，创建了哪些信息，产生了哪些信息，数据去向何处，谁进行了测量等。 - 数据建模–
从业务显示中收集的信息被精炼为一堆有望帮助业务的信息对象(元素)。区分质量(每个元素的字符)，并表征这些信息对象(物质)之间的连接。 - 流程建模–
更改信息演示阶段中表征的数据对象，以完成对执行业务工作很重要的信息流。处理的目的是添加，更改，擦除或恢复信息对象。 - 应用程序生成–
机械化的工具被用来鼓励产品的开发；即使他们利用第四种GL策略。 - 测试与周转–
自从RAD强调重用以来，已经尝试了很多编程段。这减少了一般测试时间。尽可能地，应该尝试新的部分，并且应该完全设计出所有接口。
何时使用RAD模型?
- 当框架必须进行风险化时，集中精力的能力有限(2-3个月)。
- 在必要性明显的时候。
- 在特殊危险受到限制的时候。
- 需要制作一个框架，该框架可以在60-90天的时间内进行模块化。
- 仅在财务计划允许使用已编程的代码创建设备的情况下，才应使用该代码。
RAD模型的首选位置：
- 该模型可适应变化。
- RAD的每个阶段都对客户具有最值得注意的需求有用性。
- 它减少了升级时间。
- 它建立了突出显示的可重用性。
RAD模型的负担：
- 必须包括客户。
- 在高度专业化的危险中，这是不合理的。
- 对于比较普通的企业，我们无法利用RAD模型。
- RAD无法实现所有应用程序。
- 它需要非常有天赋的创始人。