本篇博客为大家整理软件工程中的七种过程模型，供大家学习参考！！！
如有侵权，请联系作者。

---

前言

过程模型为软件工程工作提供了特定的路线图，该路线图规定了所有活动的流程、动作、任务、迭代的程度、工作产品及要完成的工作应如何组织。

“混乱的边缘”——有序和混乱之间的一种自然状态，结构化和反常之间的重大妥协。过程模型试图在找出混乱世界中的秩序和适应不断发生变化这两种要求之间寻找平衡。

---

惯用过程模型有时称为“传统”过程模型（Prescriptive Models）

一、惯用过程模型（A Generic Process Model）

1.瀑布模型（the waterfall model）

瀑布模型又称为经典生命周期，它提出了一个系统的、顺序的软件开发方法，从用户需求规格说明开始，通过策划、建模、构建和部署的过程，最终提供完整的软件支持。

1. 模型特点：
   （1）严格的线性模型结构
   （2）固定的阶段划分
   （3）大量的文档驱动
   （4）阶段性的评审机制
2. 模型解释：
   （1）瀑布模型的过程，将从上一项活动接收该项活动的工作对象（输入），实施该项活动应完成的内容给出该项活动的工作成果，传给下一项活动（输出）。
   （2）“瀑布”的理解，像瀑布一样自顶向下，过程不可逆。前一阶段完成，才进行下一阶段。
   （3）由于固定的阶段划分，每个阶段会完成规定的文档以保证后续阶段的进行。为了保证文档的正确性，每个阶段结束前都会对文档进行评审。这是必要的。
3. 模型存在的问题：
   （1）阻塞：由于模型的线性特性，在项目中会发生“阻塞状态”。（想像一下如果你是后一阶段的项目开发者，前一阶段的开发存在问题没办法解决的时候，你只能选择等待）
   （2）变更：软件实际项目的发展会面临变更流，变更可能造成混乱。（就好比瀑布自顶向下流，在下游无法改变上游的流向）。
4. 模型适用性：
   （1）适用于需求确定且清晰，开发过程无大的变更流的软件开发。
   （2）不适用于需要快速开发、交付，需求模糊且易产生变更的软件开发。
5. 模型变体——V模型，本质上是添加一系列测试（质量保证动作）。
   

2.增量模型（the incremental model）

增量模型综合了线性过程流和并行过程流的特征，随着时间的推移，在每个阶段都运用线性序列。整体上，按照瀑布模型的流程实施项目开发；软件的实际创建中，将软件系统按功能分解为许多增量构件，并以构件为单位逐个地创建与交付，直到全部增量构件创建完毕，集成到系统之中交付用户使用。

1. 模型特点
   （1）将待开发软件系统模块化
   （2）将待开发软件系统组件化
2. 模型解释
   （1）“增量”的理解，从一组给定的需求开始，通过构造一系列可执行中间版本来实施开发活动。第一个版本纳入一部分需求，下一个版本纳入更多的需求，依此类推，直到系统完成。每个中间版本都要执行必需的过程、活动和任务。
   （2）第一个增量为核心产品（core product），满足最基本的需求，许多附加的特性（有些已知，但可以先不做；有些未知；）没有提供，客户对核心产品进行评估，然后制定下一各增量计划。
   （3）我自己的理解：这与我们平时写算法的过程也类似，首先完成最基本功能的输入输出，做好“模块化”，然后再根据题目中更多的要求对算法各部分进行增加，最后完成最终的代码。（大致意思，比喻可能不准确）
3. 模型的优点
   （1）模块化，分批次提交软件产品，便于用户及时了解项目进展。
   （2）组件化，减少软件开发风险，一个开发周期的错误不会影响到整个软件系统。
   （3）开发顺序灵活，可以按照组件优先级实现。逐渐扩展，便于用户在开发过程中需求渐渐明朗，有效适应用户需求的变更。
4. 模型适用性
   （1）适用于可以分批次交付、系统可模块化的软件，或者开发人员对相关领域不熟悉难以一次性开发，项目管理人员有较高把握全局水平的开发。
   （2）不适用于软件系统很难被模块化的软件开发。

3.并行模型（the parallel model）

并行模型主要以开发过程中的主要技术活动和任务为框架，描述了开发过程中主要技术活动和任务的并行性。并行开发模型关注开发活动之间的并行性以及它们的相互关系，使项目管理者能够了解其项目当前的总体状态，便于他们有针对性地实施有效的项目管理。

1. 模型特点
   并行性
2. 模型解释
   （1）“并行”的理解，开发过程中的活动、任务、动作同时进行。
   （2）并行模型强调开发周期短，并且需求充分理解且项目范围受限，且高度模块化。
   （这很好理解，比如小A和小B一起去写一篇文章，采用并行的方式得到良好效果的情况
   情况一：小A和小B所写文章的相对较短。
   情况二：小A和小B十分清楚两个人所写的内容，并且自己可以应付自己部分的问题。
   情况三：小A和小B所写的文章最好采用的结构是分部结构，并且部分之间相关性不高。）
3. 模型存在的问题
   （1）“并行”需要大量的人力资源，随着项目的复杂程度增加所需要的人力资源大于线性增加。
   （2）项目在实际开发中经常会有组件间的调整，并行开发无法解决。
   （3）一旦项目存在较高的技术风险（新技术），并行开发可能发生严重的后果。
4. 模型适用性
   （1）适用：参考模型解释（2）
   （2）不适用：参考模型存在的问题

原型模型、抛弃原型模型、螺旋模型属于演化过程模型，演化过程模型（the evolutionary model）属于传统过程模型

4.原型模型（the prototyping model）

很多时候，客户定义了软件的一些基本任务，但是没有详细定义功能和特性需求。另一种情况下，开发人员可能对算法的效率、操作系统的适用性和人机交互的形式等情况并没有把握。在这些情况和类似情况下，采用原型开发模型。

1. 模型特点
   快速构建、容易修改
2. 模型解释
   （1）第一个原型很少是好用的，太慢、太大、太不友好等
   （2）原型模型不要求高完整性，快速、易修改在原型模型的使用上很关键，因为原型模型的“试探性”的特点能渐进地启发客户提出新的需求或任务（促使开发人员和用户达成共识）。
   （3）减少资源浪费，避免需求不确定在开发工程中的资源浪费。（结合我自己的理解，我喜欢素描，因为素描在一定程度上就是原型模型，开始勾勒最简单的轮廓，画出一个大致效果，可能这个效果在自己审视的时候（自己就是用户）会发现许多地方太过冗杂，就会擦掉一些，在不断修改的过程中，也是激发自己灵感的过程，最终确定好需求和设计，逐步演化为最终的图画）。
3. 模型存在的问题
   （1）客户：客户喜欢的版本可能还包含一定的问题（“chewing gum”），作为开发者告诉客户需要重构时，客户可能只希望尽可能少的修改，甚至不修改（很多时候“客户为王”，项目最终还是要卖给客户）。
   （2）开发人员：开发人员可能会为了“利益”拿原型给客户，牺牲“质量”，赚“快钱”。
   （3）软件：缺少完整性和长期可维护性，容易导致产品被抛弃
4. 模型适用性
   （1）适用于用户需求模糊、经常变化，系统规模不太大也不太复杂的软件开发。
   （2）虽然原型可以作为一个独立的过程模型，但是更多时候是作为一种技术，可以在本博客提到的任何一种模型中使用。即使需求很模糊时，原型模型都能帮助软件开发人员和利益相关者更好地理解究竟需要做什么。

5.抛弃原型模型（the throwaway prototyping model）

原型模型是一种用户需求驱动的方法，分为非抛弃型原型模型和抛弃型原型。（这里单独拿出抛弃原型模型，为了强调“抛弃”的作用）

1. 基本思路
   抛弃原型模型的根本作用是弄清楚需求和为风险评估提供补充信息。通过评估后，原型被抛弃，重新规划和实施系统的开发。
2. 模型的解释
   （1）参考5原型模型
   （2）“抛弃”特性十分重要，对于技术不熟悉、特别复杂、相关性依赖性较强的软件，适时的“抛弃”是必要的。在不断设计原型和临时系统，在了解清楚需求和设计，对原有模型进行适度的“抛弃”，并不像非抛弃原型进行重构和修改，很多时候并不是重构上出了问题，而是在需求和设计就出问题，功能就没搞清楚。
3. 区别
   （1）非抛弃原型模型——建模快速设计、易修改。抛弃原型模型——“试探”模型，与客户沟通，确定需求和设计。
   （2）接着以“素描”来理解一下非抛弃原型模型和抛弃原型模型。
   非抛弃：买画的人将一个具体的“杯子”放在你面前让你画，那么你很大程度上是了解需求和设计，快速开始，只需要不断地重构，修改，最终可以呈现不错地效果。
   抛弃：如果告诉你画一个杯子，但你事先并不了解“杯子”，也不知道要设计成什么样的杯子，那么在不断的设计原型，和买画的人沟通要画成什么样子，最终确定设计和需求，按照非抛弃的过程完成，会获得不错的效果。

6.螺旋模型（the spiral model）

螺旋模型是一种演进式软件过程模型。它结合了原型的迭代性质和瀑布模型的可控性和系统性特点。它具有快速开发越来越完善的软件版本的潜力。螺旋模型是一种风险驱动型的过程模型生成器，对于软件集中的系统，它可以指导多个利益相关者的协同工作。

1. 模型特点
   （1）采用循环的方式逐步加深系统定义和实现的深度，同时降低风险。
   （2）确定一系列里程碑作为支撑点，确保利益相关者认可是可行的且令各方满意的系统解决方案。
2. 模型解释
   （1）每次演进都要考虑风险，每个演进过程还要标记里程碑（沿着螺旋路径达到的工作产品和条件的结合体）。
   （2）螺旋模型第一圈一般开发出产品的规格说明，接下来开发产品原型，并在每次迭代中完善。开始的规模小，也比较稳定，后续逐渐展开。
   （3）应用在计算机软件的整个生命周期，本质上，当螺旋模型以图中方式进行下去，永远保持可操作性，直到软件的生命周期结束。过程经常会处于休眠状态，但当有变更时，过程总能够在合适的入口点启动（如产品提高）。
3. 模型存在的问题
   （1）使用螺旋模型每一圈完成都会重新计划和修改项目开销，预算固定的开发，螺旋模型会无法控制收益。（鱼和熊掌不可兼得，风险和收益也一样）。
   （2）风险驱动，那么就很依赖风险评估，如何让客户（最好以合同形式）认定风险、相信演进方向，如何去找到权威的评估专家保证成功，这都是潜在的难题。
4. 模型适用性
   开发大型系统和软件很实际的方法（但要解决好上面描述的模型存在的问题）。

二、敏捷开发（Agile Development）

7.极限编程过程（模型）（eXtreme Programming,XP）

极限编程是一个轻量级的、灵巧的软件开发方法，同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气（任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。）

XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期，通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

1. 极限编程过程
   （1）策划（planing）
   a. 倾听用户故事
   b. 客户根据对应特征和功能的综合业务价值表明故事的价值（权值）
   c. 验收测试标准
   d. 迭代计划（项目速度等）
   （2）设计（designing）
   a. KIS原则
   b. 重构原则
   （3）编码（coding）
   a. 单元测试（测试先行）
   b. 结对编程
   （4）测试（testing）
   a. 每天进行系统的集成和确认测试
   b. 接受测试
2. XP模型特征：
   （1）增量和反复式的开发----一次小的改进跟着一个小的改进。
   （2）反复性，通常是自动重复的单元测试，回归测试。参见JUnit。
   （3）结对编程
   （4）在程序设计团队中的用户交互（在场的客户）
   （5）软件重构
   （6）共享的代码所有权
   （7）简单
   （8）反馈
   （9）用隐喻来组织系统
   （10）可以忍受的速度
3. 模型适用性
   不适用于不熟悉的领域（技术）或太复杂的软件开发。

三、场景小练习

1. 场景
   W公司是全球一个大型咨询公司，旗下咨询师员工分布全球，提供各类不同的咨询服务。目前，为了识别和跟踪各咨询师的项目经验，公司打算建设一个新的知识管理系统。假设这个系统所提供的功能是全新的，在W及同类企业里面从未尝试过。目前虽然W已经实现网络化，但位于不同国家的办公室使用的软件与硬件尚未统一。公司希望此系统可以在一年以内开
   发成功并投入使用。
2. 需求
   为W公司选择一个合适的过程模型，并解释选择的原因。

给大家一个我自己的手写稿的分析，欢迎大家批评指正。

---

参考

《软件工程-实践者的研究方法》（《Software Engineering: A Practitioner’s Approach》, 7/e (McGraw-Hill, 2009)）