本文共 2331 字，大约阅读时间需要 7 分钟。

引言

软件过程就是从软件项目需求定义至软件运行维护的整个生命周期过程中系统开发、运行和维护所实施的全部过程。软件过程模型/软件生命周期模型就是一种开发策略，这种策略针对软件工程的各个阶段提供了一套范形，使工程的进展达到预期的目的。

对一个软件的开发无论其大小，我们都需要选择一个合适的软件过程模型，这种选择基于项目和应用的性质、采用的方法、需要的控制，以及要交付的产品的特点

⭐️瀑布模型/线性模型/传统生命周期模型

经典 传统

瀑布模型是一个特别经典，老套的周期模型，一般情况下将其分为计划、需求分析、概要设计、详细设计、编码、测试、运行维护等几个阶段。

瀑布模型的周期是环环相扣的。每个周期中交互点都是一个里程碑，上一个周期的结束需要输出本次活动的工作结果，本次的活动的工作结果将会作为下一个周期的输入。 但是，如果当某一个阶段出现了不可控的问题的时候，就会导致返工到上一个阶段，甚至会延迟下一个阶段。 💡一般自己写过项目的，都是按这个流程走的。

优点

• 项目开发分为清晰明确的几个阶段，次序固定，自上而下。
• 以文档为驱动，降低开发成本。
• 阶段间具有顺序性和依赖性（有利有弊）。
• 每个阶段必须完成规定的文档，每个阶段结束前完成文档审查，及早改正错误。

缺点

• 实际项目很难遵循瀑布模型提出的理性顺序，需求可能变更。
• 客户通常难以清晰描述所有需求。
• 客户需要有耐心，只有项目完成才能看到所开发的软件。

V模型

注重测试 质量保证

V模型实际上是瀑布模型的变体，可以看到他很多步骤都和瀑布模型相似。只不过V模型把测试分为多个阶段，更加强调开发过程中的质量保证。

优点

• 清楚的标识了开发和测试的各个阶段，包含底层测试（单元测试）和高层测试（系统测试）。
• 自上而下逐步求精，每个阶段分工明确，便于整体项目的把控。

缺点

• 自上而下的顺序导致测试工作在编码后，不能及时的进行修改。
• 实际工作中，需求经常变化，导致V模型步骤反复执行，返工量很大，灵活度较低。
  缺点和瀑布模型类似

快速原型模型

快速 先画原型图

快速原型模型的第一步就是创建一个快速原型，让开发者与用户直接可以通过原型进行交互，再进行充分的讨论和分析，最终弄清楚当前系统的需求，最后在原型的基础上开发出用户满意的产品。

优点：

• 可以快速为用户提供一个可以看到的原型软件。
  💡就像刚刚说的，很多时候用户自己也不知道自己的需求，直接画出来是最牢靠的方式。
• 可有效应对需求的不确定性，避免浪费人力。

缺点

• 整个软件可能是随意搭成的 ， 开发者没有考虑整体软件质量与长期的可维护性。
• 采用了一些折中手段让系统快速运行起来，比如不合适的操作系统、开发语言、低效算法等。
  💡很多中小公司开发个项目，找个模版工程套一下，自己再简单去网上粘几个功能代码，不管合理不合理，也不管性能如何，只要能跑起来就万事大吉，这就是典型的快速原型开发。😓

渐增模型/增量模型/迭代模型

拆分 增量构件

迭代模型摒弃了传统的需求分析，设计，编码，测试的流程，将整个生命周期划分成若干冲刺阶段（又称增量构建）。使用增量模型开发软件时， 把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。

💡个人理解就是把功能给细分，一个一个来开发，一步一步来往产品上加功能。

优点

• 能在较短时间内向用户提交可完成部分工作的产品。
• 逐步增加产品功能，使用户有更多时间学习和适应产品，减少一个全新软件可能给用户带来的冲击。
• 开发可以在一开始不用投入过多的人力资源。
• 可以有效管理技术风险。

缺点

• 与瀑布模型和快速原型模型相比增量模型需要更精心的设计，有时开发者很难给出大小适合的增量。
  💡很好理解，一开始拆分不好，可能后来的开发直接翻盘。
• 一方面把软件看作一个整体，另一方面又要求把软件看作一个个构件序列，这就要求开发人员要有很强的技术能力。

螺旋模型

注重风险 谨慎

螺旋模型尤其重视风险分析阶段，特别适用于庞大并且复杂，高风险的项目。

螺旋模型通常由四个阶段组成：制定计划、风险分析、实施工程和客户评估。 螺旋模型中，发布的第一个模型甚至可能是没有任何产出的，可能仅仅是纸上谈兵的一个目标，但是随着一次次的交付，每一个版本都会朝着固定的目标迈进，最终得到一个更加完善的版本。 💡螺旋模型适用于一个风险很高且很大的工程，所以务必要谨慎地分析风险。

优点

• 支持用户需求的动态变化。
• 原型可看作形式的可执行的需求规格说明，易于为用户和开发人员共同理解，还可作为继续开发的基础，并为用户参与所有关键决策提供了方便。
• 特别强调原型的可扩充性和可修改性 ，原型的进化贯穿整个软件生存周期，这将有助于目标软件的适应能力。
• 为项目管理人员及时调整管理决策提供了方便，进而可降低开发风险

缺点

• 如果每次迭代效率不高，致使迭代次数过多将会增加成本并推迟提交时间。
• 使用该模型需要有相当丰富的风险评估经验和专门知识，要求开发队伍水平较高。

喷泉模型

界限不明显 可同步开发

喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步开发。

💡简单来说就是各阶段随意开始，不考虑顺序，有什么需求立即就开始干。

优点

• 提高开发效率，节省开发时间。

缺点

• 由于开发过程重叠，可能需要大量开发人员，不利于项目的管理。
• 此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。

改进的喷泉模型

转载地址：https://suprit.blog.csdn.net/article/details/115417987 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！