【软考架构】再谈软件过程模型（论瀑布模型、快速原型模型、增量模型、螺旋模型间的区别与关系）

前言

就软考架构师所涉及的软件工程考点范围来说，我个人认为软件过程模型部分是最抽象、难理解、易混淆的知识区。在上一轮备考学习中，我为自己建立了“软件过程模型就是构建软件生命周期的模具”这一似乎自洽的逻辑（详见《【软考架构】我理解的软件过程模型》），最近又学习到这里，对一些具体的经典模型产生了更深刻的认知，故通过撰写本文梳理思绪，同时也是辅助记录当下感受以便将来回顾。

虽说现在行业普遍采用的是敏捷模型，但一方面敏捷模型过于丰富不便展开，另一方面愚以为敏捷模型是低维度的、更具体的实操方法，就探讨软件过程模型这一高度抽象的概念而言不如朴素模型那样联系紧密，因此本文将不作详述。

软件过程模型的起源

在软件工程领域，瀑布模型被广泛认为是‌最早的标准开发模型，由‌温斯顿·罗伊斯（Winston Royce）‌于‌1970年‌正式提出，其核心思想是将软件开发流程划分为‌线性顺序的多个阶段‌（如需求分析、设计、编码、测试等），强调阶段间的严格顺序性和文档化输出‌。虽然在今天看来，这一理论存在诸多弊病，但在当时主要是为了调和另一个极端而产生的。

在上个世纪70年代前，软件开发过程普遍是“边做边改”的混沌状态，需求模糊、流程混乱，导致项目失败率高且维护困难‌。瀑布模型作为首个系统化的软件开发模型填补了方法论的空白，为行业提供了统一流程参考，推动了软件工程学科的形成‌。其对软件开发流程中各个工作阶段的定义，以及通过规范的工作流程来约束开发过程从而促进软件产品质量提升的核心思想，是后来各种方法论诞生、发展的基础。

虽说人类工程化思想的发展已经经历了上千年，但就软件开发这一新兴行业而言，瀑布模型的提出仍称得上是具有划时代意义的。

理论的演进

无序开发由于灵活应变的特性，至今仍存在于许多小微型项目上，正如罗伊斯发表的论文题目中所写的《Managing the Development of Large Software Systems》，瀑布模型最初就是为了应对大型项目而诞生的理论。早期由于大型系统主要集中在军工、航天等注重过程严谨的领域，需求明确且变更较少，该方法论还不会表现出非常激烈的矛盾。但随着技术的平民化，软件行业需求不明确、易变动的问题使得瀑布模型过于僵硬的问题日益凸显。于是，随着越来越多的行业涉足软件工程，工程人员不断在瀑布模型的基础上进行调整、适配，从而建立了一系列新的指导思想。

受限于笔者有限的职业水平，恕不能穷举前人们进行理论创新的根本出发点，本文仅通过分享我对快速原型模型、增量模型、螺旋模型这三个模型的理解，浅析它们各自的出发点，从而探寻面对不同方法论时快速理解其理论创新的源头的朴素方法。

风险与成本的管控

笔者以为，一切工程方法论的创新最终目的都是为了管控风险和成本、提升效益。这里的效益不是简单的物质回报，也包括了社会影响、可持续发展等更为宏大的议题，因此理论上是能够容纳所有矛盾点的。

从更加空泛的角度来说，人类活动的许多问题都来自于不确定性，这在软件工程领域尤为明显。正如最初提出瀑布模型是为了应对大型项目中秩序混乱导致的风险、成本居高难下的问题，后来的多数理论创新也是为了解决需求不明确、易变动等带来的研发方向偏航风险、人力物力成本浪费、伪需求或无法实现的需求等问题。为了让不确定变得确定，工程人员尝试了许多方法，其中就包括产品模拟让需求确定、分批交付让反馈确定、增量分析让风险确定，即笔者认为的快速原型模型、增量模型、螺旋模型的根本出发点。

通过提升确定性，可以有效减少无效开发、资源分配不合理等资源浪费现象，还能提升风险的可预测性，更及时有效地应对风险。

三种模型的方法论

对于初学者来说，要理解这三种模型的方法论，首先需要理清各自名称的含义。“快速原型”可以拆解为“快速”和“原型”两部分，即“要构建用于模拟的产品原型，并且还要快速地构建”；“增量”增的是产品交付的量，与瀑布模型中的阶段性交付在语义上相似，但其实客体有本质区别；螺旋模型的螺旋和马哲发展观中螺旋式上升的螺旋是一个意思，都描述了一个每一轮都相似但本质在演进的、循环往复的过程。

建立原型的直接作用是模拟产品使用，相对于凭空讲述，有原型的辅助显然能获得更直观的感受，从而有助于让用户提出更明确的需求。快速制作的原型必然相对粗糙，因此快速原型中建立的原型倾向于抛弃式，往往只用于提取需求。由于原型还可以用于实现阶段的参照和交付阶段的验证等，因此快速原型模型会存在原型这一资源的浪费的问题，但相对于后续的设计、实现等产品开发过程，甚至上线使用的生产过程中发生的资源浪费，这点浪费是可以接受的。以短期原型成本换取长期需求准确性正是快速原型模型的核心逻辑。由于协助用户提炼需求需要投入一定的资源，为了降低项目风险，快速原型模型注重通过多轮迭代来逼近真实需求。这样做的另一个好处是，由于迭代是由粗到细的，在技术上越是高抽象层次中隐含的问题越会容易靠前暴露，从而降低后期在高层设计上调整需求所带来的风险。

增量模型强调将较大的系统拆分为可以独立交付运行的子功能，以支持分批交付，让用户尽早使用系统，并在项目还在开发过程中就能提供使用反馈，便于开发团队更高效地改进系统。该模型适用于用户能够提供相对清晰的需求，但是每个阶段只能提供部分需求，或者需求整体尚不稳定，可能有较大变动的情形，此时真实的使用体验比清晰完整的需求更重要。增量模型可以视为现代敏捷模型的前身，都强调快速交付和持续改进。区别在于由于历史原因，增量模型受瀑布模型直接影响较大，仍然注重前期规划的预见性，是“有规划、有秩序”的“边做边完善”，而敏捷模型则强化了适应性方面的理论，相对弱化了预见性的重要性，从而更贴合现代软件产品日益复杂多变的趋势。

读者如果看过一些软考架构师的辅导资料，大概也被灌输过“只要提到风险就一定是螺旋模型”这样的认知。就我浏览过的有限的资料中，虽然都提及了这个技巧，但是都没有把个中缘由讲清楚到能让资质愚钝的我深刻理解的程度。和技术问题不同的是，方法论问题一般只有合理的范围而鲜有标准的答案，因此惰于深入查阅文献的我结合粗浅了解的马哲理论和轻易获得的相关概述，为自己构建了这样的自洽逻辑：螺旋模型是为复杂、高风险的大型项目设计的，而通过多轮的迭代，在每一轮迭代中有节制地完善已知、可控的部分以使系统有序地逐渐精进能够有效控制风险的尺度和范围。落实到项目开发中就是将每一轮都划分为计划、风险分析、开发、评审四个阶段，每一轮都以上一轮的成果为基础建立更完善的原型，不断补充已掌控风险的覆盖面，最终实现最大程度地抑制风险点转为现实的可能性。所以螺旋模型并不要求每一轮循环后都有可用的产品交付，这一点和增量模型有本质区别。此外，四个阶段中虽然只有风险分析阶段提到了风险，但实际上计划、评审同样有抑制风险扩散的作用，而且开发阶段也能通过建立严格的约束规范加强风险管控。更为严谨的是，传统的迭代或增量对于反查已经完成的部分投入的资源会比待开发部分少很多，往往只对发现问题的部分小修小补，而螺旋模型中每旋转一周，断面都会增大一个尺度，对应到工作中就是每并入一个子模块都会扩大一点联调范围，最终形成一个不仅子模块内部经过多轮修正后稳定可靠，而且模块之间的协作也历经磨合达到严丝合缝的大型系统。

总结

总的来说，快速原型是在不做原型和做详尽原型间折中，借助模拟产品快速提取需求以应对需求模糊不清的问题，通过多轮迭代由粗到细地精化产品；增量模型是用户虽然有相对清晰的需求但尚未稳定，需要通过使用产品获得真实感受从而提供有效的反馈来改进产品，为了控制项目周期而将产品拆分为可以相对独立运行的子模块分批交付；螺旋模型是通过控制工作面缓速增大来反复验证产品分部、各部协作的有效性，从而将大型系统的各种风险控制在最低。

从各自产生的背景来说，设计应用场景高度确定的瀑布模型本就不该包含原型这种应对不确定性问题的产物，而另外三种都是为了提升确定性而从不同角度作了调整，因此实操中都会或多或少地涉及到原型构建。作为初代系统性的软件工程理论，后来的软件过程模型必然都会有瀑布模型的影子，快速原型模型和增量模型可以理解为从迭代和增量两个方向上对瀑布模型进行补充。螺旋模型注重风险管控，理论上不应该在迭代性和增量性间二选一，实际工作中从不同角度解读也能得到不同的定性。但就应试而言，当面临极限三选一时，由于螺旋模型中每一轮循环都会覆盖已完成部分，从定义上相较于增量更接近与迭代，而在距离上相比瀑布模型快速原型模型离得更近，因此最佳选择是脱胎于快速原型模型。

The end.