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 构建。
需要高技能的开发人员/设计师。
对建模技能的高度依赖。
不适用于较便宜的项目，因为建模和自动代码生成的成本非常高。
管理复杂性较多。
适用于基于组件且可扩展的系统。
需要用户参与整个生命周期。
适合需要较短开发时间的项目。