SDLC - 快速应用开发模型

---

---

快速应用开发 (RAD) 模型基于原型和迭代开发，无需具体的规划。软件本身的编写过程就包含了开发产品所需的规划。

快速应用开发专注于通过研讨会或焦点小组收集客户需求，使用迭代概念让客户尽早测试原型，重用现有原型（组件），持续集成和快速交付。

什么是 RAD？

快速应用开发是一种软件开发方法，它使用最少的规划来支持快速原型设计。原型是一个功能上等同于产品组件的工作模型。

在 RAD 模型中，功能模块并行开发为原型，并集成以创建完整的最终产品，从而加快产品交付。由于没有详细的预先规划，因此更容易在开发过程中整合更改。

RAD 项目遵循迭代和增量模型，并拥有由开发人员、领域专家、客户代表和其他 IT 资源组成的小型团队，这些团队逐步处理其组件或原型。

要使该模型成功，最重要的一点是确保开发的原型可重用。

RAD 模型设计

RAD 模型将分析、设计、构建和测试阶段分配到一系列短暂的迭代开发周期中。

以下是 RAD 模型的各个阶段：

业务建模

针对正在开发的产品设计业务模型，内容包括信息流以及信息在各个业务渠道之间的分配。进行完整的业务分析，以查找业务的关键信息，如何获取信息，如何以及何时处理信息，以及哪些因素推动了信息流的成功。

数据建模

审查和分析在业务建模阶段收集的信息，以形成对业务至关重要的数据集。识别和定义所有数据集的属性。根据业务模型，详细建立和定义这些数据对象之间的关系。

流程建模

将数据建模阶段定义的数据对象集转换为业务信息流，以根据业务模型实现特定的业务目标。在此阶段定义任何更改或增强数据对象集的流程模型。给出添加、删除、检索或修改数据对象的流程描述。

应用程序生成

使用自动化工具将流程和数据模型转换为实际原型，从而构建实际系统并进行编码。

测试和交付

在 RAD 模型中，总测试时间减少了，因为原型在每次迭代期间都独立测试。但是，需要对所有组件之间的数据流和接口进行彻底测试，并实现完整的测试覆盖率。由于大多数编程组件都已通过测试，因此可以降低出现任何重大问题的风险。

下图详细描述了 RAD 模型。

Explore our latest online courses and learn new skills at your own pace. Enroll and become a certified expert to boost your career.

RAD 模型与传统 SDLC

传统的 SDLC 遵循严格的流程模型，在编码开始之前高度重视需求分析和收集。它给客户施加压力，要求在项目开始之前签署需求，而且客户无法感受到产品的实际效果，因为很长时间内都没有可用的工作版本。

客户在看到软件后可能需要进行一些更改。但是，更改过程非常严格，在传统的 SDLC 中可能无法实现对产品进行重大更改。

RAD 模型专注于向客户迭代和增量交付工作模型。这导致快速交付给客户，并在产品的整个开发周期中实现客户参与，从而降低了与实际用户需求不符的风险。

RAD 模型 - 应用

可以将 RAD 模型成功应用于可以进行清晰模块化的项目。如果项目无法分解成模块，则 RAD 可能会失败。

以下要点描述了可以使用 RAD 的典型场景：

• 仅当系统可以模块化以增量方式交付时，才应使用 RAD。

• 如果建模人员高度充足，则应使用它。

• 仅当预算允许使用自动代码生成工具时，才应使用它。

• 只有在有具备相关业务知识的领域专家的情况下，才应选择 RAD SDLC 模型。

• 应该在项目期间需求发生变化并且需要以 2-3 个月的短迭代向客户展示工作原型的情况下使用。

RAD 模型 - 优点和缺点

RAD 模型由于组件的可重用性和并行开发，缩短了整体开发时间，从而实现了快速交付。只有在高技能工程师可用且客户也致力于在给定的时间范围内实现目标原型的情况下，RAD 才能良好运行。如果任何一方缺乏承诺，该模型都可能失败。

RAD 模型的优点如下：

• 可以适应不断变化的需求。

• 可以衡量进度。

• 使用强大的 RAD 工具可以缩短迭代时间。

• 在短时间内用较少的人员提高生产力。

• 缩短开发时间。

• 提高组件的可重用性。

• 可以进行快速初步审查。

• 鼓励客户反馈。

• 从一开始就集成可以解决许多集成问题。

RAD 模型的缺点如下：

• 依赖技术能力强的团队成员来识别业务需求。

• 只有可以模块化的系统才能使用 RAD 构建。

• 需要高技能的开发人员/设计师。

• 高度依赖建模技能。

• 不适用于较便宜的项目，因为建模和自动代码生成的成本非常高。

• 管理复杂性更高。

• 适用于基于组件且可扩展的系统。

• 需要用户在整个生命周期中参与。

• 适用于需要较短开发时间的项目。