软件开发模型-瀑布模型、V形模型、原型模型、增量模型、快速开发、敏捷模型

0x01 边做边改模型

边做边改模型如同他的字面意思一样，可以理解为，开始没有架构框架，通过在软件开发的过程中去整改，遇到问题才会去整改。

可以看到，很多的项目管理的考试中都包含了软件开发模型的类别，因为不能称作是真正的模型，所以很少有提到边做边改模型。但是在一些包含安全架构，安全开发的考试中就会提到，之所以会包含，是因为很多厂家都在采用这个方法。

0x02 瀑布模型

瀑布模型是将项目活动分解为线性顺序阶段，其中每个阶段取决于前一个阶段的可交付成果，可以理解成线性生命周期的方法，在上一个阶段完成后，下一个阶段才开始。
在软件开发中，它往往是迭代性和灵活度较低的方法之一，因为进展在很大程度上沿一个方向流动（像瀑布一样“向下” ）通过概念、启动、分析、设计、构建、测试等阶段，部署和维护。

这种模型比较适合小型项目，在开始就已经明确需求和目标，这个模型就可以很好的提供架构框架，但在变更或不确定性较高的项目中，这种方法就不适合。

总结一下瀑布模型的主要应用场景：

• 需求明确清晰且固定，后期没有较大变动
• 产品定义明确，有明确目标
• 项目周期短
• 技术固定
• 目标明确，没有不明确的选择
• 具有所需专业知识的充足资源可用于支持产品

瀑布模型可能存在的问题：

• 高风险和不确定性的项目不适合
• 对于复杂和面向对象的项目不适合
• 长期和持续项目不适合
• 不适合需求处于中度到高度变更风险的项目
• 很难分阶段衡量进展情况
• 无法适应不断变化的需求

0x03 V形模型

首先接上面的瀑布模型：如果在复杂的大型项目中，容易错过需求阶段本身的关键细节。在这种情况下，一个完全错误的产品将交付给客户，可能需要重新开始项目，但在软件的设计和架构中犯了严重错误，项目经理和团队将不得不重新设计整个软件来纠正错误。

为了解决上面的问题，提出了V 模型。

V 模型是一个高度规范的 SDLC 模型（ SDLC 是软件开发生命周期），其中有一个与每个开发阶段平行的测试阶段。V形模型与瀑布模型最大的不同在于，V形模型不再采用瀑布模型的平面线性方式，反而增加了每个阶段的验证和确认功能。

验证和确认的区别
验证：验证产品是否满足了产品规范
确认：是否通过合适的方式，针对问题提出了必要的解决方法

V形模型相比瀑布模型更高效的地方在于，V形模型在每个阶段结束后，都判断了结果，结果达到标准后再进行下一阶段。

0x04 原型模型

原型模型要求在进行实际软件开发之前，应建立系统的工作原型。
原型通常是实际系统的一个非常粗糙的版本，与实际软件相比，可能表现出有限的功能能力、低可靠性和低效的性能。
在许多情况下，客户只能对软件产品的期望有一个大致的了解。在没有关于系统输入、处理需求和输出需求的详细信息的这种情况下，可以使用原型模型。

原型模型的优点：

• 支持早期产品营销
• 降低维护成本
• 由于系统是并排的，因此可以更早地检测到错误

原型模型的缺点：

• 一个不稳定/执行不善的原型通常会成为最终产品

• 花费大

• 很难知道该项目将持续多久

• 耗时长

• 快速原型：快速开发一个原型模型，开发的原型不一定是最终接受的原型的一部分

• 递进原型：渐进形式，过程中不断演化，也就是最初开发的原型在客户反馈的基础上逐步完善，直到最终被接受

• 运行原型：实在开发环境中的对原型的改进

0x05 增量模型

在增量模型中，首先有一个完整的可交付的系统，然后随着改变和更新，每次增量都会产出一个可交付成果，也就是在每次进行增量模型时，都会对原产品进行改进。

增量模型有助于以增量方式交付发布序列，从而加快每个功能的开发进度。
每个开发的功能都会一个接一个地交付给最终用户，第一个增量始终是基本功能，其他功能在新版本的下一个增量中添加，以防客户在审核第一个版本后请求添加任何新功能。
这个过程一直进行到开发出完整的产品。

优点在于，每次都会在一个可交付的成果上进行改进，提高了效率，并且反馈的结果易于修改产品。

0x06 螺旋模型

软件测试中的螺旋模型是一种适用于增量和原型技术的测试策略。螺旋模型看起来像一个带有许多循环的螺旋。螺旋的确切圈数是未知的，并且可能因项目而异。
对于风险高且开发和测试逐步进行的大型复杂项目，通常遵循螺旋模型策略。螺旋模型也称为螺旋生命周期模型。螺旋模型是由 Barry Boehm 于 1985 年引入的。

螺旋模型阶段

• 计划
• 风险分析
• 开发和测试
• 评估

• 计划阶段：确定目标和替代解决方案，从客户那收集需求，并在每个阶段开始时确定、详细说明和分析目标。然后在该象限中提出了该阶段可能的替代解决方案。
• 风险分析阶段：在第二象限，识别和解决风险，评估所有可能的解决方案以选择最佳解决方案。然后识别与该解决方案相关的风险，并使用最佳策略解决风险。
• 开发和测试阶段：在第三象限，通过测试开发和验证识别的功能。在第三象限结束时，可以使用软件的下一个版本。
• 评估阶段：客户评估目前开发的软件版本。

0x07 快速应用程序开发模型 (RAD)

快速应用程序开发模型由 IBM 在 1980 年代首次提出。
如果可以将项目分解为小模块，其中每个模块可以独立分配给不同的团队，则可以使用此模型实施软件项目。

快速应用程序开发模型优点：

• 提供了更强的灵活性，因为开发人员可以在创建过程中适应变化并结合新的特性和功能
• 可以进行快速迭代，以缩短时间框架并使交付过程更加简化
• 基于客户协作，从而满足所有利益相关者，如开发人员、客户和用户
• 提供了更好的风险管理解决方案，因为在最终确定之前解决了代码漏洞

0x08 敏捷模型

敏捷模型的主要目的是帮助项目快速适应变更请求,促进项目的快速完成。
敏捷性是通过使流程适合项目来实现的，消除对特定项目可能不是必需的活动并避免任何浪费时间和精力的事情。

敏捷模型的优点在于，可以促进跨部门的合作及更优的反馈机制。

在敏捷模型中，需求被分解成许多可以增量开发的小部分。敏捷模型采用迭代开发，每个增量部分都是在一次迭代中开发的。每次迭代都旨在小型且易于管理，并且可以在几周内完成。

敏捷模型是增量模型和迭代模型的集合，阶段包含：

• 需求收集
• 需求分析
• 设计
• 编码
• 单元测试
• 验收测试

敏捷模型通过结对编程产生编写良好的紧凑程序，与单独工作的程序员相比，错误更少，减少了整个项目的总开发时间。