几种常见软件过程模型的比较

一、瀑布模型（Waterfall Model）

瀑布模型（经典生命模型）提出了软件开发的系统化的、顺序的方法。其流程从用户需求规格说明开始，通过策划、建模、构建和部署过程，最终提供一个完整的软件并提供持续的技术支持。

模型特点：

必须等前一阶段的工作完成之后，才能开始后一段的工作；
每一阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。
前一阶段的输出文档就是后一阶段的输入文档，因此，只有前一阶段的输出文档正确，后一阶段的工作才能得到正确的结果。
每个阶段结束前都要对所完成的文档进行评审，以便及早发现问题，改正错误。事实上越是早期阶段犯下的错误，暴露出来的时间就越晚，排除故障改正错误所需付出的代价也越高。因此，及时审查，是保证软件质量，降低软件成本的重要措施。

模型优点：

强调了开发的阶段性，各阶段具有顺序性和依赖性
强调早期调研和需求分析，推迟编码实现的观点
提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

模型局限：

瀑布模型是一种线性模型，要求项目严格按规程推进，必须等到所有开发工作全部完成以后才能获得可以交付的软件产品。不能对软件系统进行快速创建，对于一些急于交付的软件系统的开发很不方便。
瀑布模型适合于需求明确，且无大的需求变更的软件开发（编译系统、操作系统等）。而对于分析初期需求模糊的项目，瀑布模型也并不适合。

适用场景：

适用于需求确定，无大的需求变更，工作能够采用线性的方式完成的软件。

二、增量模型（Incremental Model）

增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，它对软件过程的考虑是：在整体上按照瀑布模型的流程实施项目开发，以方便对项目的管理；但在软件的实际开发中，则将软件系统按功能分解为许多增减构件，并以构件为单位逐个地创建与交付，直到全部增量构件创建完成，并都被集成到系统之中交付用户使用。

模型特点：

当使用增量模型时，第一个增量往往是核心的产品；
客户对每个增量的使用和评估都作为下一个增量发布的新特性和功能；
该模型采用随着日程时间的进展而交错的线性雪猎，每一个线性序列产生软件的一个可发布的“增量”。

模型优点：

第一个可交付版本所需要的成本和时间很少；
开发由增量表示的小系统所承担的风险不大；
由于很快发布了第一个版本，因此可以减少用户需求的变更；
运行增量投资，即在项目开始时，可以仅对一个或两个增量投资；

模型局限：

管理发生的成本、进度和配置的复杂性可能会超出组织的能力；
如果没有对用户的变更要求进行规划，那么产生的出事增量可能会造成后来增量的不稳定；
如果需求不想早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布。

适用场景：

项目在既定的商业要求期限之前不可能找到足够的开发人员的情况。

三、演化模型（Evolutionary Model）

快速原型（Rapid Prototype）模型

软件开发过程中，开发初期很难得到一个完整的、准确的需求规格说明，开发者往往对要解决的应用问题模糊不清，以至于形成的需求规格说明常常是不完整的、不准确的，有时甚至是有歧义的。此外，在整个开发过程中，用户可能会产生新的要求，导致需求的变更。为了适应这种需求的不确定性和变化，于是出现了快速原型（Rapid Prototype）开发方法。

模型特点：

快速原型是用来获取用户需求的，或是用来试探设计是否有效的。一旦需求或设计确定下来了，原型就将被抛弃。因此，快速原型要求快速构件、容易修改，以节约原型创建的成本、加快开发速度；
快速原型是暂时适用使用的，因此并不要求完整。它往往针对某个局部问题建立专门原型，如界面原型、工作流原型等；
快速原型不能贯穿软件的整个生命周期，它需要和其他的过程模型相结合才能产生作用。例如，在瀑布模型中应用快速原型，以解决瀑布模型在需求分析时期存在的不足。

模型优点：

能渐进地启发客户提出新的要求或任务，促使开发人员和用户达成共识；
减少了开发风险，避免了因为需求不确定而在开发过程中浪费了大量的资源。

模型局限：

没有考虑到软件的整体和长期的可维护性；
可能由于达不到质量要求而导致产品被抛弃，从而采用新的模型重新设计；

适用场景：

原型方法比较适用于用户需求不清、需求经常变化的情况。当系统规模不是很大也不太复杂时，采用该方法比较好。

螺旋模型（Spiral Model）

对于复杂的大型软件，开发一个原型往往达不到要求。螺旋模型将瀑布模型和演化模型结合起来，加入了两种模型均忽略的风险分析，弥补了这两种模型的不足。

四个步骤：

制定计划：确定软件的目标，选定实施方案，明确项目开发的限制条件；
风险评估：分析所选的方案，识别风险，消除风险；
实施工程：实施软件开发，验证阶段性产品；
用户评估：评价开发工作，提出修正建议，建立下一个周期的开发计划。

模型特点：

与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便；
使用螺旋模型进行软件开发，需要开发人员具有相当丰富的风险评估经验和专门知识。

模型优点：

关注软件的重用；
关注早期错误的消除；
将质量目标放在首位；
将开发阶段与维护阶段结合在一起。

模型局限：

开发人员需要有较强的风险评估的经验；
契约开发通常需要事先指定过程模型和发布产品。

适用场景：

螺旋模型强调风险分析，使得开发人员和用户对美俄演化层出现的风险有所了解，从而做出应有的反应。因此，该模型适合用于庞大、复杂并且具有高风险的系统。

四、喷泉模型（Water Fountain Model）

喷泉模型是专门针对面向对象软件开发方法而提出的。“喷泉”一词用于形象地表达面向对象软件开发过程中的迭代和无缝过渡。

在面向对象方法中，对象既是对现实问题中实体的抽象，也是构造软件系统的基本元素。因此，建立对象模型在面向对象方法中，既可以用于分析，也可以用于设计，而且分析阶段所获得的对象框架模型可以无缝过渡到设计阶段，以作为软件实现的依据。

喷泉模型的过程方法所考虑的是，基于面向对象方法所带来的便利，对软件的分析、设计和实现按照迭代的方式交替进行，并通过进化的方式，使软件分阶段逐渐完整、逐步求精。

模型特点：

喷泉模型是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法；
喷泉模型使开发过程具有迭代性和无间隙性，迭代意味着模型中的开发活动常常需要重复多次，在迭代过程中不断地完善软件系统，无间隙是指在开发活动（如分析、设计、编码）之间不存在明显的边界。

模型优点：

喷泉模型的各个阶段没有明显的界线，开发人员可以同步进行。其优点是可以提高如阿健项目的开发效率。节省开发时间。

模型局限：

由于喷泉模型在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，不利于项目的管理；
喷泉模型要求严格管理文档，使得审核的难度加大。

五、基于构件的开发模型（Component-baseed Development Model）

基于构件的开发方法是指利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件，也可以是商品化成品构件。基于构件的开发模型具有许多螺旋模型的特点，它本质上是演化模型，需要以迭代方式构件软件。其不同之处在于，基于构件的开发模型采用预先打包的软件构件开发应用领域。

六、形式化方法模型（Formal Methods Model）

形式化方法是建立在严格数字基础上的一种软件开发方法，其主要活动是生成计算机软件形式化的数学规格说明

七、统一过程（UP）模型

统一过程模型是一种“用例和风险驱动，以架构为中心、迭代并且增量”的开发过程，由 UML 方法和工具支持。迭代的意思是将整个软件开发项目划分为许多个小的“袖珍项目”，每个“袖珍项目”都包含正常软件项目的所有元素：计划、分析和设计、构造、集成和测试，以及内部和外部的发布。

八、敏捷开发（Agile Development）

敏捷开发的总体目标是通过“尽可能地、持续地对有价值的软件的交付”使客户满意。通过在软件开发过程中加入灵活性，敏捷方法使用户能够在开发周期的后期增加或改变需求。

敏捷过程的典型方法有很多，每一种方法基于一套原则，这些原则实现了敏捷方法所宣称的理念（敏捷宣言）。

极限编程（XP）

XP 是敏捷开发的典型方法之一，是一种轻量级（敏捷）、高效、低风险、柔性、可预测的、科学的软件开发方法，它由价值观、原则、实践和行为4个部分组成。

四大价值观：沟通、简单性、反馈和勇气。
五大原则：快速反馈、简单性假设、逐步修改、提倡更改和优质工作。
12 个最佳实践：计划游戏、小型发布、隐喻、简单设计、测试先行、重构、结对编程、集体代码所有制、持续集成、每周工作40个小时、现场客户和编码标准。

水晶法（Crystal）

水晶方法体系与 XP 一样，都有一人为中心的理念，但在实际上有所不同。水晶方法体系考虑到人们一般很难严格遵循一个纪律约束很强的过程，认为每一个项目都需要一套不同的策略、约定和方法论。因此，与 XP 的高度纪律性不同，水晶方法体系探索了用最少纪律约束而仍能成功的方法，从而在产出效率与易于运作上达到一种平衡。