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