SDLC - 快速指南

SDLC - 概述

软件开发生命周期（SDLC）是软件行业用来设计、开发和测试高质量软件的过程。SDLC 旨在生产满足或超出客户期望的高质量软件，在时间和成本估算内完成。

SDLC 是软件开发生命周期的缩写。
它也称为软件开发过程。
SDLC 是一个定义软件开发过程中每个步骤执行的任务的框架。
ISO/IEC 12207 是软件生命周期过程的国际标准。它旨在成为定义开发和维护软件所需的所有任务的标准。

什么是SDLC？

SDLC 是软件组织内软件项目遵循的流程。它包含一个详细的计划，描述如何开发、维护、替换、更改或增强特定软件。生命周期定义了提高软件质量和整体开发过程的方法。

下图是典型 SDLC 各个阶段的图形表示。

典型的软件开发生命周期由以下阶段组成 -

第一阶段：规划和需求分析

需求分析是SDLC中最重要、最基础的阶段。它由团队的高级成员根据客户、销售部门、市场调查和行业领域专家的意见执行。然后，该信息用于规划基本项目方法，并在经济、运营和技术领域进行产品可行性研究。

质量保证要求的规划和与项目相关的风险的识别也在规划阶段完成。技术可行性研究的结果是定义可以遵循的各种技术方法，以最小的风险成功实施项目。

第 2 阶段：定义要求

完成需求分析后，下一步就是明确定义和记录产品需求，并获得客户或市场分析师的批准。这是通过SRS（软件需求规范）文档来完成的，该文档包含项目生命周期中要设计和开发的所有产品需求。

第三阶段：设计产品架构

SRS是产品架构师为要开发的产品提出最佳架构的参考。根据 SRS 中指定的要求，通常会提出一种以上的产品架构设计方法，并将其记录在 DDS（设计文档规范）中。

该DDS经过所有重要利益相关者的审查，并根据风险评估、产品稳健性、设计模块化、预算和时间限制等各种参数，为产品选择最佳设计方法。

设计方法清楚地定义了产品的所有架构模块及其与外部和第三方模块（如果有）的通信和数据流表示。所提出的架构的所有模块的内部设计都应该在 DDS 中用最微小的细节来明确定义。

第四阶段：构建或开发产品

在 SDLC 的这个阶段，实际开发开始并构建产品。在此阶段根据DDS生成编程代码。如果以详细且有组织的方式进行设计，则可以毫不费力地完成代码生成。

开发人员必须遵循其组织定义的编码指南，并使用编译器、解释器、调试器等编程工具来生成代码。使用不同的高级编程语言（例如 C、C++、Pascal、Java 和 PHP）进行编码。编程语言是根据正在开发的软件类型来选择的。

第五阶段：测试产品

该阶段通常是所有阶段的子集，因为在现代 SDLC 模型中，测试活动主要涉及 SDLC 的所有阶段。然而，该阶段是指产品的仅测试阶段，其中报告、跟踪、修复和重新测试产品缺陷，直到产品达到SRS中定义的质量标准。

第六阶段：市场部署和维护

一旦产品经过测试并准备好部署，就会在适当的市场上正式发布。有时，产品部署根据该组织的业务策略分阶段进行。该产品可能首先在有限的细分市场中发布，并在真实的业务环境中进行测试（UAT-用户验收测试）。

然后，根据反馈，产品可能会按原样发布，或者在目标细分市场中添加建议的增强功能。产品投放市场后，针对现有客户群进行维护。

SDLC 型号

在软件开发过程中定义和设计了各种软件开发生命周期模型。这些模型也称为“软件开发过程模型”。每个过程模型都遵循其类型特有的一系列步骤，以确保软件开发过程的成功。

以下是业内最重要和最受欢迎的 SDLC 模型 -

瀑布模型
迭代模型
螺旋模型
V型
大爆炸模型

其他相关方法包括敏捷模型、RAD 模型、快速应用程序开发和原型模型。

SDLC - 瀑布模型

瀑布模型是第一个引入的过程模型。它也称为线性顺序生命周期模型。它非常容易理解和使用。在瀑布模型中，每个阶段必须在下一阶段开始之前完成，并且阶段之间没有重叠。

瀑布模型是最早用于软件开发的 SDLC 方法。

瀑布模型以线性顺序流程说明了软件开发过程。这意味着开发过程中的任何阶段只有在前一阶段完成后才开始。在此瀑布模型中，各个阶段不重叠。

瀑布模型 - 设计

瀑布方法是第一个在软件工程中广泛使用的 SDLC 模型，以确保项目的成功。在“瀑布”方法中，软件开发的整个过程分为不同的阶段。在此瀑布模型中，通常，一个阶段的结果依次充当下一阶段的输入。

下图展示了瀑布模型的不同阶段。

瀑布模型中的连续阶段是 -

需求收集和分析- 在此阶段捕获要开发的系统的所有可能需求并记录在需求规范文档中。
系统设计- 在此阶段研究第一阶段的需求规格并准备系统设计。该系统设计有助于指定硬件和系统要求，并有助于定义整体系统架构。
实施- 根据系统设计的输入，系统首先在称为单元的小程序中开发，这些程序将在下一阶段集成。每个单元都针对其功能进行开发和测试，这称为单元测试。
集成和测试- 在实施阶段开发的所有单元在每个单元测试后都集成到系统中。集成后，将对整个系统进行测试以排除任何故障和故障。
系统部署- 功能和非功能测试完成后；产品部署在客户环境中或发布到市场。
维护- 客户端环境中出现一些问题。为了解决这些问题，发布了补丁。为了增强产品，还发布了一些更好的版本。维护是为了在客户环境中交付这些更改而进行的。

所有这些阶段都是相互级联的，其中进展被视为在这些阶段中稳定地向下流动（像瀑布一样）。只有在实现上一阶段定义的目标并签署后，才会开始下一阶段，因此名称为“瀑布模型”。在此模型中，阶段不重叠。

瀑布模型 - 应用

每个开发的软件都是不同的，需要根据内部和外部因素采用合适的 SDLC 方法。最适合使用瀑布模型的一些情况是 -

需求有很好的记录、清晰且固定。
产品定义稳定。
技术是可以理解的并且不是动态的。
没有任何含糊的要求。
有足够的资源和所需的专业知识来支持该产品。
项目时间短。

瀑布模型 - 优点

瀑布式开发的优点是允许部门化和控制。可以为每个开发阶段设定一个时间表和最后期限，并且产品可以一个接一个地完成开发过程模型阶段。

开发从概念开始，经过设计、实施、测试、安装、故障排除，最后到操作和维护。每个开发阶段都严格按照顺序进行。

瀑布模型的一些主要优点如下 -

简单易懂和使用
由于模型的刚性，易于管理。每个阶段都有特定的可交付成果和审查流程。
一次处理并完成一个阶段。
非常适合需求非常容易理解的小型项目。
明确定义的阶段。
很好理解的里程碑。
轻松安排任务。
过程和结果都有详细记录。

瀑布模型 - 缺点

瀑布式开发的缺点是不允许太多的反思或修改。一旦应用程序进入测试阶段，就很难返回并更改在概念阶段没有充分记录或考虑的内容。

瀑布模型的主要缺点如下 -

直到生命周期的后期才生产出可用的软件。
高风险和不确定性。
对于复杂和面向对象的项目来说，这不是一个好的模型。
对于长期和正在进行的项目来说，这是一个糟糕的模型。
不适合需求变化风险为中度到高度的项目。因此，该流程模型的风险和不确定性很高。
很难衡量阶段内的进展。
无法适应不断变化的需求。
在生命周期中调整范围可能会结束项目。
集成是在最后以“大爆炸”的方式完成的，这不允许及早发现任何技术或业务瓶颈或挑战。

SDLC - 迭代模型

在迭代模型中，迭代过程从一小部分软件需求的简单实现开始，并迭代地增强不断发展的版本，直到完整的系统被实现并准备好部署。

迭代生命周期模型并不尝试从完整的需求规范开始。相反，开发从指定和实现软件的一部分开始，然后对其进行审查以确定进一步的需求。然后重复此过程，在模型的每次迭代结束时生成新版本的软件。

迭代模型 - 设计

迭代过程从软件需求子集的简单实现开始，并迭代地增强不断发展的版本，直到实现完整的系统。在每次迭代中，都会进行设计修改并添加新的功能。此方法背后的基本思想是通过重复循环（迭代）和一次较小的部分（增量）来开发系统。

下图是迭代和增量模型的表示 -

迭代和增量开发是迭代设计或迭代方法与增量构建模型的组合进行开发。“在软件开发过程中，软件开发周期的多个迭代可能同时进行。” 这个过程可以被描述为“进化获取”或“增量构建”方法。

在这个增量模型中，整个需求被分为不同的构建。在每次迭代期间，开发模块都会经历需求、设计、实现和测试阶段。该模块的每个后续版本都会在先前版本的基础上添加功能。该过程持续进行，直到完整的系统按照要求准备就绪。

成功使用迭代软件开发生命周期的关键是严格验证需求，并根据模型每个周期内的这些需求对每个版本的软件进行验证和测试。随着软件在连续的周期中不断发展，必须重复和扩展测试以验证软件的每个版本。

迭代模型 - 应用

与其他 SDLC 模型一样，迭代和增量开发在软件行业中有一些特定的应用。该模型最常用于以下场景 -

整个系统的要求被明确定义和理解。
必须定义主要要求；然而，某些功能或要求的增强功能可能会随着时间的推移而发展。
市场有时间限制。
开发团队在项目工作过程中正在使用和学习一项新技术。
具有所需技能集的资源不可用，计划根据合同用于特定迭代。
有些高风险功能和目标将来可能会发生变化。

迭代模型 - 优点和缺点

这种模型的优点是在系统开发的早期阶段就有一个工作模型，这使得更容易发现功能或设计缺陷。在开发的早期阶段发现问题可以在有限的预算内采取纠正措施。

这种SDLC模型的缺点是它仅适用于大型且庞大的软件开发项目。这是因为很难将小型软件系统分解为更小的可服务增量/模块。

迭代和增量 SDLC 模型的优点如下：

一些工作功能可以在生命周期的早期快速开发。
尽早并定期获得结果。
可以规划并行开发。
进展是可以衡量的。
更改范围/要求的成本较低。
在较小的迭代期间进行测试和调试很容易。
在迭代过程中识别并解决风险；每次迭代都是一个易于管理的里程碑。
更容易管理风险 - 首先完成高风险部分。
每一次增量都会交付可操作的产品。
从每个增量中识别出的问题、挑战和风险可以利用/应用于下一个增量。
风险分析比较好。
它支持不断变化的需求。
初始操作时间较短。
更适合大型关键任务项目。
在生命周期中，软件尽早生产，有利于客户评估和反馈。

迭代和增量 SDLC 模型的缺点如下：

可能需要更多资源。
虽然变更成本较小，但不太适合变更需求。
需要更多的管理关注。
系统架构或设计问题可能会出现，因为并非所有需求都在整个生命周期的开始时收集。
定义增量可能需要定义整个系统。
不适合较小的项目。
管理复杂性较多。
项目结束可能不知道，这是一个风险。
风险分析需要高技能的资源。
项目进展高度依赖于风险分析阶段。

SDLC - 螺旋模型

螺旋模型将迭代开发的思想与瀑布模型的系统性、受控性相结合。这种螺旋模型是迭代开发过程模型和顺序线性开发模型（即高度强调风险分析的瀑布模型）的结合。它允许产品的增量发布或通过螺旋的每次迭代进行增量细化。

螺旋模型 - 设计

螺旋模型有四个阶段。软件项目在称为螺旋的迭代中反复经历这些阶段。

鉴别

此阶段从收集基线螺旋中的业务需求开始。在随后的产品成熟螺旋中，系统需求、子系统需求和单元需求的识别都是在这个阶段完成的。

此阶段还包括通过客户和系统分析师之间的持续沟通来了解系统需求。在螺旋的末端，产品被部署在确定的市场中。

设计

设计阶段从基线螺旋中的概念设计开始，涉及后续螺旋中的架构设计、模块逻辑设计、物理产品设计和最终设计。

建造或建造

构造阶段是指在每个螺旋中实际软件产品的生产。在基线螺旋中，当刚刚想到产品并开发设计时，在此阶段开发 POC（概念验证）以获得客户反馈。

然后，在随后的螺旋式上升中，需求和设计细节更加清晰，称为构建的软件工作模型会产生，并带有版本号。这些构建将发送给客户以获取反馈。

评估与风险分析

风险分析包括识别、估计和监控技术可行性和管理风险，例如进度延误和成本超支。测试构建后，在第一次迭代结束时，客户评估软件并提供反馈。

下图是螺旋模型的表示，列出了每个阶段的活动。

根据客户的评估，软件开发过程进入下一个迭代，随后按照线性方法实施客户建议的反馈。沿着螺旋的迭代过程在软件的整个生命周期中持续进行。

螺旋模型应用

螺旋模型广泛应用于软件行业，因为它与任何产品的自然开发过程同步，即成熟地学习，这对客户和开发公司来说风险最小。

以下指针解释了螺旋模型的典型用途 -

当预算有限且风险评估很重要时。
适用于中高风险项目。
由于随着时间的推移，需求发生变化，经济优先事项可能发生变化，因此需要长期项目承诺。
客户不确定自己的要求，这是通常的情况。
需求很复杂，需要进行评估才能清晰。
新产品线应分阶段发布，以获得足够的客户反馈。
在开发周期中，产品预计会发生重大变化。

螺旋模型 - 优点和缺点

螺旋生命周期模型的优点在于，它允许在产品元素变得可用或已知时添加它们。这确保了与之前的要求和设计不发生冲突。

此方法与具有多个软件构建和发布的方法一致，允许有序地过渡到维护活动。该方法的另一个积极方面是螺旋模型迫使用户尽早参与系统开发工作。

另一方面，完成此类产品需要非常严格的管理，并且存在无限循环螺旋运行的风险。因此，变更的纪律和接受变更请求的程度对于成功开发和部署产品非常重要。

螺旋SDLC模型的优点如下：

可以满足不断变化的要求。
允许广泛使用原型。
可以更准确地捕获需求。
用户很早就看到了系统。
开发可以分为较小的部分，并且可以更早地开发有风险的部分，这有助于更好的风险管理。

螺旋 SDLC 模型的缺点如下：

管理比较复杂。
项目的结束可能无法提前得知。
不适合小型或低风险项目，并且对于小型项目可能会很昂贵。
工艺复杂
螺旋可能会无限期地持续下去。
大量的中间阶段需要大量的文档。

SDLC - V 型

V 模型是一种 SDLC 模型，其中流程的执行以 V 形的顺序方式发生。它也称为验证和确认模型。

V模型是瀑布模型的扩展，并且基于每个相应开发阶段的测试阶段的关联。这意味着对于开发周期中的每个阶段，都有一个直接相关的测试阶段。这是一个高度严格的模型，下一阶段只有在上一阶段完成后才开始。

V 型 - 设计

在V模型下，开发阶段的相应测试阶段是并行规划的。因此，“V”的一侧有验证阶段，另一侧有验证阶段。编码阶段连接 V 模型的两侧。

下图描述了 SDLC V 模型中的不同阶段。

V 模型 - 验证阶段

V 模型中有多个验证阶段，下面详细解释每个阶段。

业务需求分析

这是开发周期的第一阶段，从客户的角度理解产品需求。此阶段涉及与客户的详细沟通，以了解他的期望和确切要求。这是一项非常重要的活动，需要妥善管理，因为大多数客户不确定他们到底需要什么。验收测试设计规划在此阶段完成，因为业务需求可以用作验收测试的输入。

系统设计

一旦您有了清晰、详细的产品需求，就可以设计完整的系统了。系统设计将了解并详细说明正在开发的产品的完整硬件和通信设置。系统测试计划是根据系统设计制定的。在早期阶段执行此操作可以为稍后的实际测试执行留出更多时间。

建筑设计

在此阶段理解和设计架构规范。通常会提出不止一种技术方法，并根据技术和财务可行性做出最终决定。系统设计进一步分解为具有不同功能的模块。这也称为高层设计 (HLD)。

内部模块之间以及与外界（其他系统）之间的数据传输和通信在此阶段被清楚地理解和定义。有了这些信息，就可以在此阶段设计和记录集成测试。

模块设计

在此阶段，指定所有系统模块的详细内部设计，称为低级设计（LLD）。设计与系统架构中的其他模块以及其他外部系统兼容非常重要。单元测试是任何开发过程的重要组成部分，有助于在早期阶段消除最大的故障和错误。这些单元测试可以在这个阶段根据内部模块设计来设计。

编码阶段

设计阶段设计的系统模块的实际编码在编码阶段进行。最合适的编程语言是根据系统和架构要求决定的。

编码是根据编码指南和标准进行的。在将最终构建签入存储库之前，代码会经过多次代码审查并针对最佳性能进行优化。

验证阶段

下面详细解释了 V 模型中的不同验证阶段。

单元测试

在模块设计阶段设计的单元测试在此验证阶段对代码执行。单元测试是代码级别的测试，有助于在早期阶段消除错误，尽管单元测试无法发现所有缺陷。

集成测试

集成测试与架构设计阶段相关。执行集成测试是为了测试系统内内部模块的共存和通信。

系统测试

系统测试与系统设计阶段直接相关。系统测试检查整个系统功能以及正在开发的系统与外部系统的通信。在此系统测试执行过程中可以发现大多数软件和硬件兼容性问题。

验收测试

验收测试与业务需求分析阶段相关，并涉及在用户环境中测试产品。验收测试揭示了与用户环境中可用的其他系统的兼容性问题。它还可以发现实际用户环境中的负载和性能缺陷等非功能性问题。

V-型号 ─ 应用

V模型的应用与瀑布模型几乎相同，都是顺序类型的。在项目开始之前，需求必须非常明确，因为返回并进行更改通常成本高昂。该模型用于医学开发领域，因为它是一个严格遵守纪律的领域。

以下是一些最适合使用 V 模型应用程序的场景。

需求定义明确、记录清晰且固定。
产品定义稳定。
技术不是动态的，并且被项目团队很好地理解。
不存在任何含糊或未定义的要求。
项目时间短。

V 模型 - 优点和缺点

V模型方法的优点是非常容易理解和应用。该模型的简单性也使其更易于管理。缺点是模型对变化不灵活，万一出现需求变化（这在当今的动态世界中很常见），进行更改的成本就会变得非常昂贵。

V模型方法的优点如下：

这是一种纪律严明的模型，每个阶段一次完成一个。
非常适合需求非常容易理解的小型项目。
简单且易于理解和使用。
由于模型的刚性，易于管理。每个阶段都有特定的可交付成果和审查流程。

V模型方法的缺点如下：

高风险和不确定性。
对于复杂和面向对象的项目来说，这不是一个好的模型。
对于长期和正在进行的项目来说，这是一个糟糕的模型。
不适合需求变化风险为中度到高度的项目。
一旦应用程序进入测试阶段，就很难返回并更改功能。
直到生命周期的后期才生产出可用的软件。

SDLC - 大爆炸模型

Big Bang 模型是一个 SDLC 模型，我们不遵循任何特定流程。开发只是从所需的资金和精力作为输入开始，输出是开发的软件，可能符合也可能不符合客户的要求。这个大爆炸模型不遵循流程/程序，并且需要很少的规划。即使客户也不确定他到底想要什么，并且需求是在没有太多分析的情况下即时实现的。

通常，开发团队规模很小的小型项目会遵循此模型。

大爆炸模型─设计与应用

大爆炸模型包括将所有可能的资源集中在软件开发和编码中，而很少或根本没有计划。需求一出现就被理解和实施。所需的任何更改可能需要也可能不需要改进整个软件。

该模型非常适合由一两个开发人员一起工作的小型项目，并且对于学术或实践项目也很有用。对于需求尚未被充分理解且未给出最终发布日期的产品来说，这是一个理想的模型。

大爆炸模型 - 优点和缺点

这种大爆炸模型的优点是它非常简单，并且需要很少的规划或不需要规划。易于管理，无需正式程序。

然而，大爆炸模型是一种风险非常高的模型，需求的变化或需求的误解甚至可能导致项目的完全逆转或报废。它非常适合风险最小的重复性或小型项目。

大爆炸模型的优点如下：

这是一个非常简单的模型
很少或不需要规划
易于管理
所需资源很少
为开发人员提供灵活性
对于新来者或学生来说，这是一个很好的学习辅助工具。

大爆炸模型的缺点如下：

非常高的风险和不确定性。
对于复杂和面向对象的项目来说，这不是一个好的模型。
对于长期和正在进行的项目来说，这是一个糟糕的模型。
如果需求被误解，可能会变得非常昂贵。

SDLC-敏捷模型

敏捷SDLC模型是迭代和增量过程模型的组合，通过快速交付工作软件产品来关注过程适应性和客户满意度。敏捷方法将产品分解为小的增量构建。这些构建是在迭代中提供的。每次迭代通常持续大约一到三周。每次迭代都涉及跨职能团队在各个领域同时工作，例如 -

规划
需求分析
设计
编码
单元测试和
验收测试。

在迭代结束时，将向客户和重要的利益相关者展示工作产品。

什么是敏捷？

敏捷模型认为，每个项目都需要以不同的方式处理，现有的方法需要进行定制以最适合项目的要求。在敏捷中，任务被划分为时间框（小时间范围），以交付版本的特定功能。

采用迭代方法，并在每次迭代后交付工作软件构建。每个版本在功能方面都是增量的；最终版本包含客户所需的所有功能。

这是敏捷模型的图解说明 -

敏捷思维过程始于软件开发的早期，并因其灵活性和适应性而随着时间的推移而开始流行。

最流行的敏捷方法包括 Rational Unified Process (1994)、Scrum (1995)、Crystal Clear、极限编程 (1996)、自适应软件开发、功能驱动开发和动态系统开发方法 (DSDM) (1995)。2001 年敏捷宣言发布后，这些现在统称为敏捷方法论。

以下是敏捷宣言的原则 -

个体和交互- 在敏捷开发中，自组织和动机很重要，协同定位和结对编程等交互也很重要。
工作软件- 演示工作软件被认为是与客户沟通以了解其需求的最佳方式，而不仅仅是依赖文档。
客户协作- 由于各种因素，在项目开始时无法完全收集需求，因此持续的客户交互对于获得正确的产品需求非常重要。
响应变化- 敏捷开发专注于对变化的快速响应和持续开发。

敏捷与传统 SDLC 模型

敏捷基于自适应软件开发方法，而传统的 SDLC 模型（如瀑布模型）基于预测方法。传统 SDLC 模型中的预测团队通常会进行详细的规划，并对未来几个月或产品生命周期内要交付的确切任务和功能有完整的预测。

预测方法完全取决于周期开始时完成的需求分析和规划。任何要合并的变更都要经过严格的变更控制管理和优先级排序。

敏捷使用自适应方法，没有详细的规划，并且仅在需要开发哪些功能方面明确未来的任务。有功能驱动的开发，团队动态适应不断变化的产品需求。该产品通过发布迭代进行了非常频繁的测试，最大限度地降低了未来发生重大故障的风险。

客户交互是这种敏捷方法的支柱，并且以最少的文档进行开放式沟通是敏捷开发环境的典型特征。敏捷团队彼此密切协作，并且通常位于同一地理位置。

敏捷模型 - 优点和缺点

敏捷方法最近在软件界被广泛接受。然而，这种方法可能并不总是适合所有产品。以下是敏捷模型的一些优点和缺点。

敏捷模型的优点如下：

是一种非常现实的软件开发方法。
促进团队合作和交叉训练。
功能可以快速开发和演示。
资源要求最低。
适用于固定或变化的要求
提供早期的部分工作解决方案。
对于稳定变化的环境来说是一个很好的模型。
最少的规则，易于使用的文档。
在总体规划的环境中实现并行开发和交付。
很少或不需要规划。
易于管理。
为开发人员提供了灵活性。

敏捷模型的缺点如下 -

不适合处理复杂的依赖关系。
可持续性、可维护性和可扩展性的风险更大。
总体计划、敏捷领导者和敏捷 PM 实践是必须的，没有它们，一切都将无法进行。
严格的交付管理规定了要交付的范围、功能以及按时完成的调整。
很大程度上取决于客户互动，因此如果客户不清楚，团队可能会被引导向错误的方向。
由于生成的文档最少，因此个人依赖性非常高。
由于缺乏文档，向新团队成员转让技术可能相当具有挑战性。

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

SDLC - 软件原型模型

软件原型是指构建软件应用程序原型，该原型显示正在开发的产品的功能，但实际上可能不保留原始软件的确切逻辑。

软件原型作为一种软件开发模型变得非常流行，因为它能够在开发的早期阶段了解客户的需求。它有助于从客户那里获得有价值的反馈，并帮助软件设计人员和开发人员了解正在开发的产品的确切期望。

什么是软件原型设计？

原型是具有一些有限功能的软件工作模型。原型并不总是保持实际软件应用程序中使用的精确逻辑，并且是在工作量估计中需要考虑的额外工作。

原型设计用于允许用户评估开发人员的建议并在实施之前进行尝试。它还有助于了解特定于用户的需求，以及开发人员在产品设计过程中可能未考虑到的需求。

以下是解释设计软件原型的逐步方法。

基本需求识别

此步骤涉及了解非常基本的产品要求，特别是在用户界面方面。在此阶段可以忽略内部设计和性能和安全性等外部方面的更复杂的细节。

开发初始原型

初始原型是在此阶段开发的，其中展示了非常基本的要求并提供了用户界面。这些功能在实际开发的软件内部可能不会以完全相同的方式工作。同时，解决方法用于在开发的原型中为客户提供相同的外观和感觉。

原型审查

然后将开发的原型呈现给客户和项目中的其他重要利益相关者。以有组织的方式收集反馈并用于进一步增强正在开发的产品。

修改和增强原型

在此阶段讨论反馈和审查意见，并根据时间和预算限制以及实际实施的技术可行性等因素与客户进行一些谈判。接受的更改再次纳入开发的新原型中，并重复该循环，直到满足客户的期望。

原型可以具有水平或垂直尺寸。水平原型显示产品的用户界面，并提供整个系统的更广阔的视野，而不专注于内部功能。另一方面，垂直原型是对产品中特定功能或子系统的详细阐述。

水平原型和垂直原型的目的不同。水平原型用于获取有关用户界面级别和业务需求的更多信息。它甚至可以在销售演示中展示，以在市场上获得业务。垂直原型本质上是技术性的，用于获取子系统确切功能的详细信息。例如，给定子系统中的数据库要求、交互和数据处理负载。

软件原型设计 - 类型

业界使用不同类型的软件原型。以下是广泛使用的主要软件原型类型 -

一次性/快速原型制作

一次性原型设计也称为快速原型设计或封闭式原型设计。这种类型的原型制作只需很少的努力和最少的需求分析即可构建原型。一旦了解了实际需求，原型就会被丢弃，并在对用户需求有更清晰了解的情况下开发实际系统。

进化原型

进化原型也称为面包板原型，基于一开始就构建具有最少功能的实际功能原型。开发的原型构成了未来原型的核心，整个系统均在此基础上构建。通过使用演化原型，可以将易于理解的需求包含在原型中，并在理解后添加需求。

增量原型设计

增量原型是指构建各个子系统的多个功能原型，然后集成所有可用的原型以形成完整的系统。

极限原型

极限原型设计用于 Web 开发领域。它由三个连续的阶段组成。首先，以 HTML 格式呈现包含所有现有页面的基本原型。然后使用原型服务层模拟数据处理。最后，服务被实施并集成到最终原型中。此过程称为“极限原型”，用于引起人们对该过程第二阶段的关注，其中开发功能齐全的 UI，而很少考虑实际服务。

软件原型设计 - 应用

软件原型在开发具有高水平用户交互的系统（例如在线系统）时最有用。需要用户在处理数据之前填写表格或浏览各种屏幕的系统可以非常有效地使用原型设计，甚至在开发实际软件之前就可以提供准确的外观和感觉。

涉及太多数据处理且大部分功能是内部的、用户界面很少的软件通常不会从原型设计中受益。在此类项目中，原型开发可能是额外的开销，并且可能需要大量的额外工作。

软件原型设计 - 优点和缺点

软件原型设计用于典型情况，应非常谨慎地做出决定，以便构建原型所花费的精力为最终开发的软件增加可观的价值。该模型有其自身的优点和缺点，讨论如下。

原型模型的优点如下：

甚至在产品实施之前就增加了用户对产品的参与度。
由于显示了系统的工作模型，用户可以更好地了解正在开发的系统。
由于可以更早地检测到缺陷，因此可以减少时间和成本。
更快的用户反馈可以带来更好的解决方案。
可以轻松识别缺失的功能。
可以识别令人困惑或困难的功能。

原型模型的缺点如下：

由于过于依赖原型而导致需求分析不充分的风险。
用户可能会对原型和实际系统感到困惑。
实际上，这种方法可能会增加系统的复杂性，因为系统的范围可能会超出原始计划。
开发人员可能会尝试重用现有原型来构建实际系统，即使这在技术上不可行。
如果没有适当的监控，在构建原型上投入的精力可能会过多。