SDLC - RAD 模型
RAD（快速应用程序开发） 模型基于原型设计和迭代开发，不涉及具体规划。 编写软件本身的过程涉及开发产品所需的计划。
快速应用程序开发侧重于通过研讨会或焦点小组收集客户需求、客户使用迭代概念对原型进行早期测试、现有原型（组件）的重用、持续集成和快速交付。
什么是RAD?
快速应用程序开发是一种软件开发方法，它使用最少的计划来支持快速原型制作。 原型是在功能上等同于产品组件的工作模型。
在 RAD 模型中，功能模块作为原型并行开发，并集成为完整的产品，以加快产品交付速度。 由于没有详细的预先计划，因此更容易将更改纳入开发过程。
RAD 项目遵循迭代和增量模型，由开发人员、领域专家、客户代表和其他 IT 资源组成的小团队逐步处理其组件或原型。
要使该模型取得成功，最重要的方面是确保开发的原型可重复使用。
RAD 模型设计
RAD 模型将分析、设计、构建和测试阶段分配到一系列简短的迭代开发周期中。
以下是 RAD 模型的各个阶段 −
商业建模
正在开发的产品的业务模型是根据信息流和各种业务渠道之间的信息分发来设计的。 执行完整的业务分析以查找业务的重要信息、获取信息的方式、处理信息的方式和时间以及推动信息成功流动的因素有哪些。
数据建模
审查和分析在业务建模阶段收集的信息，以形成对业务至关重要的数据对象集。 识别和定义所有数据集的属性。 这些数据对象之间的关系是根据业务模型详细建立和定义的。
流程建模
数据建模阶段定义的数据对象集被转换为根据业务模型建立实现特定业务目标所需的业务信息流。 在此阶段定义对数据对象集进行任何更改或增强的过程模型。 给出了添加、删除、检索或修改数据对象的过程描述。
生成应用
通过使用自动化工具将流程和数据模型转换为实际原型来构建实际系统并完成编码。
测试和迭代
RAD 模型的总体测试时间减少了，因为原型在每次迭代期间都经过独立测试。 但是，所有组件之间的数据流和接口都需要进行彻底的测试，并具有完整的测试覆盖率。 由于大多数编程组件已经过测试，因此降低了出现任何重大问题的风险。
下图详细描述了 RAD 模型。
RAD 模型与传统 SDLC
传统的 SDLC 遵循严格的流程模型，高度重视编码开始前的需求分析和收集。 它给客户施加了压力，要求他们在项目开始之前签署需求，并且由于长时间没有可用的工作构建，客户对产品没有任何感受。
客户在看到软件后可能需要进行一些更改。 然而，变更过程非常严格，在传统的 SDLC 中将产品的重大变更纳入其中可能是不可行的。
RAD 模型专注于向客户迭代和增量交付工作模型。 这导致在产品的整个开发周期中快速交付给客户和客户参与，从而降低了不符合实际用户需求的风险。
RAD 模型 - 应用
RAD 模型可以成功地应用于可以进行清晰模块化的项目。 如果项目不能分解成模块，RAD 可能会失败。
以下指针描述了可以使用 RAD 的典型场景 −
RAD 仅应在系统可以模块化以增量方式交付时使用。
如果建模设计师的可用性很高，则应该使用它。
仅当预算允许使用自动代码生成工具时才应使用它。
只有在拥有相关业务知识的领域专家可用时，才应选择 RAD SDLC 模型。
应在项目期间需求发生变化且工作原型将在 2-3 个月的小迭代中呈现给客户的情况下使用。
RAD 模型 - 优点和缺点
RAD 模型可实现快速交付，因为它由于组件的可重用性和并行开发而缩短了总体开发时间。 仅当有高技能工程师可用并且客户也承诺在给定时间范围内实现目标原型时，RAD 才能发挥良好作用。 如果双方都缺乏承诺，则该模型可能会失败。
RAD模型的优点如下 −
可以适应不断变化的要求。
进度是可以衡量的。
使用强大的 RAD 工具可以缩短迭代时间。
在短时间内用更少的人提高生产力。
缩短开发时间。
提高组件的可重用性。
进行快速初步审查。
鼓励客户提供反馈。
从一开始就集成解决了很多集成问题。
RAD模型的缺点如下 −
依靠技术过硬的团队成员来确定业务需求。
只有可以模块化的系统才能使用 RAD 构建。
需要高技能的开发人员/设计师。
高度依赖建模技能。
不适用于成本较低的项目，因为建模和自动代码生成的成本非常高。
管理复杂性更高。
适用于基于组件且可扩展的系统。
需要用户参与整个生命周期。
适合需要较短开发时间的项目。
