螺旋模型
螺旋模型
我们在瀑布模型中面临的最大问题是完成产品需要很长时间，并且软件已经过时。为了解决这个问题，我们有一种新方法，称为螺旋模型。螺旋模型也称为循环模型。
在此模型中，我们逐个模块创建应用程序并移交给客户，以便他们可以在很早的阶段开始使用应用程序。并且我们仅在模块相互依赖时才准备此模型。在这个模型中，我们分阶段开发应用程序，因为有时客户会在过程之间给出需求。
螺旋模型的不同阶段如下:
需求分析
设计
编码
测试和风险分析
需求分析
螺旋模型流程从收集业务需求开始。在这方面，以下螺旋将包括系统需求、单元需求和子系统需求的文档。在这个阶段，我们可以很容易地了解系统需求，因为业务分析师和客户有不断的沟通。并且一旦循环完成，应用程序就会在市场上部署。
设计
螺旋模型的第二阶段设计，我们将在那里计划逻辑设计、架构设计、流程图、决策树等。
编码
设计阶段编译后，我们将进入我们的下一步，这是编码阶段。在这方面，我们将根据客户的要求开发产品，并获得客户的反馈。这个阶段是指在每个周期中构建实际应用程序。
这些螺旋状结构对需求非常清晰，应用程序的设计细节被称为具有版本号的构建。之后，这些构建将传输给客户端以供其响应。
测试和风险分析
一旦开发成功完成，我们将在以下位置测试构建在第一个周期结束时，还从管理风险、检测和观察技术可行性等不同方面分析软件的风险。之后，客户端将测试应用程序并给出反馈。
螺旋模型示例
让我们看一个示例以更好地理解螺旋模型:
在螺旋模型中，软件是在小模块中开发的。假设我们有应用程序 A，这个应用程序是在 P、Q、R 等不同模型的帮助下创建的。
上图中
RP: 模块P的需求分析，与RQ、RR类似。
DP: 模块 P 的设计，与 DQ、DR 类似。
CP: 模块 P 的编码，与 CQ 类似, CR。
TP: 测试模块 P，以及类似的 TQ、TR。
在P模块中，我们先得到需求，然后才设计模块。模块 A 的编码部分在测试错误时完成。
下一个模块是Q，它是在模块P构建的时候创建的。我们遵循与模块 P 相同的过程，但是当我们开始测试模块 Q 时，我们检查以下条件，例如: 测试 Q 模块 模块Q与P的测试集成 测试模块P
在创建模块 P、Q 后，我们将进入模块 R，然后我们将按照与模块 P 和 Q 相同的过程，然后测试以下条件: 首先，检查模块为 R、Q 和 P 然后，按以下顺序检查模块的集成:
R → Q、R 和 P → P 和 Q
注意: 一旦多个模块继续循环，模块Q只能在模块P正确构建后才能构建，模块R类似。
最适合螺旋模型的示例是 MS-Excel，因为 MS-Excel 工作表具有多个单元格，这些单元格是 Excel 工作表的组成部分。由于我们要先创建单元格(模块P)，然后我们可以对单元格进行操作，例如将单元格分成两半(模块Q)，将单元格合并为两个，然后我们可以在excel表上绘制图形(模块R ).
在螺旋模型中，我们可以进行两种类型的变化，如下所示:
重大变化
小改动
重大变更
当客户要求对特定模块的需求进行重大变更时，我们只更改该模块并针对集成和单元。为此，我们总是更喜欢一个新周期，因为它可能会影响现有模块。主要变化可能是软件的功能。
小变化
每当客户要求对特定应用程序进行细微更改时，软件团队就必须在一个周期内同时进行更小的更改以及新模块的开发。而且我们从不进行任何新的循环或迭代，因为微小的变化不会影响现有功能，而且还需要额外的资源和时间。较小的更改可能是 UI(前端更改)。
优势和螺旋模型的缺点
| 优势 |
缺点 |
| 螺旋模型允许灵活变化。 |
它不适合小型和低风险的产品，因为它对于较小的项目可能会很昂贵。 |
| 开发可以分成更小的部分。 |
这是一个传统模型，因此开发人员也只做测试工作。 |
| 客户也可以在早期使用该应用程序。 |
螺旋模型中没有审查过程的要求，也不允许并行交付。 |
| 让开发人员和测试工程师更加清晰 |
在螺旋模型中，管理有点困难；这就是为什么这是一个复杂的过程。 |
| 它将提供原型的广泛使用。 |
中间阶段的最大数量需要不必要的文书工作。 |
