本节书摘来自华章出版社《软件工程方法与实践》一 书中的第3章，第3.3节，作者窦万峰，更多章节内容可以访问“华章计算机”公众号查看。
3.3 传统的软件过程模型
3.3.1 瀑布模型
在20世纪80年代之前，瀑布模型是最早也是应用最广泛的软件过程模型，现在它仍然是软件工程中应用得最广泛的过程模型。瀑布模型提供了软件开发的基本框架，其过程是接收上一项活动的工作结果作为输入，然后实施该项活动应完成的工作，并将该项活动的工作结果作为输出传给下一项活动。同时，在开始下一个阶段的活动之前需要评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。
瀑布模型将软件生存周期划分为软件计划、需求分析、软件设计、软件实现、软件测试、运行与维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。
从本质来讲瀑布模型是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布及维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是“瀑布”模型名称的由来。瀑布模型的软件过程如图3-1所示。
瀑布模型各个阶段产生的文档是维护软件产品必不可少的，没有文档的软件几乎是不可能维护的。瀑布模型中的文档约束，使软件维护变得更加容易。由于绝大部分软件预算都花费在软件维护上，因此，使软件易于维护就能显著降低软件预算。按照传统的瀑布模型开发软件，有下述的几个特点。
顺序性和依赖性。瀑布模型的各个阶段之间存在着这样的关系：后一阶段的工作必须等前一阶段的工作完成之后才能开始。前一阶段的输出文档就是后一阶段的输入文档，因此，只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。
推迟实现。对于规模较大的软件项目来说，往往编码开始得越早，最终完成开发工作所需要的时间反而越长。主要原因是前面阶段的工作没做或做得不到位，过早地进行下一阶段的工作，往往导致大量返工，有时甚至发生无法弥补的问题，带来灾难性后果。瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，分析与设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的编程实现。清楚地区分逻辑设计与物理设计，尽可能推迟程序的编程实现，是按照瀑布模型开发软件的一条重要的指导思想。
质量保证。为保证软件的质量，瀑布模型的每个阶段都应完成规定的文档，只有交出合格的文档才算完成该阶段的任务。完整、准确的合格文档不仅是软件开发时期各类人员之间相互通信的媒介，也是运行时期对软件进行维护的重要依据。其次，在每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题、改正错误。事实上，越是早期阶段犯下的错误，暴露出来的时间就越晚，排除故障、改正错误所需付出的代价也越高。
瀑布模型着重强调文档的作用，并要求每个阶段都要仔细验证。但这种模型的线性过程太理想化，已不再适合现代化软件开发的模式，其主要问题在于：
各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。事实证明，一旦一个用户开始使用一个软件，在他的头脑中关于该软件应该做什么的想法就会或多或少地发生变化，这就使得最初提出的需求变得不完全适用了。
由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；客户要等到开发周期的晚期才能看到程序运行的测试版本，而在这时发现大的错误时，其后果可能是灾难性的；实际的项目大部分情况难以按照该模型给出的顺序进行，而且这种模型的迭代是间接的，这很容易由微小的变化造成大的混乱。
3.3.2 增量模型
增量模型（incremental model）也称为渐增模型，是在项目的开发过程中以一系列的增量方式开发系统。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件由多种相互作用的模块所形成的提供特定功能的代码片段构成。
增量方式包括增量开发和增量提交。增量开发是指在项目开发周期内，在一定的时间间隔内开发部分工作软件；增量提交是指在项目开发周期内，在一定的时间间隔内以增量方式向用户提交工作软件和文档。
总体开发与增量构造模型
它在瀑布模型基础上，对一些阶段进行整体开发，如分析与设计阶段，对另一些阶段进行增量开发，如编码和测试阶段。前面的分析与设计阶段按瀑布模型进行整体开发，后面的编码与测试阶段按增量方式开发。
总体开发与增量构造模型融合了瀑布模型的基本成分和原型实现模型的迭代特征，采用随时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”，如图3-2所示。
当使用增量模型时，第一个增量往往是核心的产品，即第一个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生最终的完善产品。
总体开发与增量构造模型强调每一个增量均发布一个可操作的产品。
增量开发与增量提交模型
它在瀑布模型的基础上，所有阶段都进行增量开发，也就是说不仅是增量开发，也是增量提交。这种模型融合了线性顺序模型的基本成分和原型实现模型的迭代特征。
增量开发与增量提交模型采用随着日程时间的进展而交错的线性序列。每一个线性序列产生软件的一个可发布的“增量”。当使用演化增量提交模型时，第一个增量往往是核心的产品，也就是说第一个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估，都作为下一个增量发布的新特征和功能。这个过程在每一个增量发布后不断重复，直到产生最终的完善产品。增量开发与增量提交模型强调每一个增量均要发布一个可运行的产品。
增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的可运行产品的一个子集。整个产品被分解成若干个构件，开发人员逐个交付产品，这样软件开发可以很好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。但是，增量模型也存在以下缺陷：
各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
在实际的软件开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。
3.3.3 螺旋模型
螺旋模型（spiral model）是由Barry Boehm正式提出的模型，它将瀑布模型和快速原型模型结合起来，不仅体现了两个模型的优点，而且还强调了其他模型均忽略的风险分析，特别适合于大型复杂的系统。
螺旋模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。软件开发过程每迭代一次，软件开发又前进一个层次。螺旋模型的软件过程如图3-3所示。
螺旋模型在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。该模型沿着螺旋线进行若干次迭代，图3-3中的4个象限分别代表了以下活动：
制订计划：确定软件目标，选定实施方案，确定项目开发的限制条件。
风险分析：评估所选方案，考虑如何识别和消除风险。
实施工程：实施软件开发和验证。
客户评估：评价开发工作，提出修正建议，制订下一步计划。
螺旋模型有许多优点：
对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标。
减少了过多测试（浪费资金）或测试不足（产品故障多）所带来的风险。
在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别。
与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高目标软件的适应能力，为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发风险。
螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，帮助我们将软件质量作为特殊目标融入产品开发之中。但螺旋模型也有一定的限制条件：螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应，因此特别适用于复杂并具有高风险的系统。对于这些系统，风险是软件开发不可忽视且潜在的不利因素，它可能在不同程度上损害软件开发过程，影响软件产品的质量。减小软件风险的目标是在造成危害之前，及时对风险进行识别及分析，决定采取何种对策，进而减少或消除风险的损害。风险驱动是螺旋模型的主要优势，但在一定情况下这也可能是它的一个弱点。软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险。
另一方面，如果执行风险分析将明显影响项目的利润，那么进行风险分析就需要慎重，因此，螺旋模型只适合于大规模软件项目。事实上，项目越大，风险也越大，因此，进行风险分析的必要性也越大。此外，只有内部开发的项目，才能在风险过大时中止项目。