4.测试：在这一阶段，独立的组件和集成后的组件都将进行系统性验证以确保没有错误并且完全符合第一阶段所制定的需求。一个独立的质量保证小组将定义“测试实例”来评估产品是完全实现了需求还是只有部分满足。
有三种测试方法可以使用：对独立的代码模块进行单元测试；对集成产品进行系统测试；以及客户参与的验收测试。如果发现了缺陷，将会对问题进行记录并向开发团队反馈以进行修正。在这一阶段，还有产品文档会经过准备、评估并发布，比如用户手册等。
5.安装：在产品通过测试并且被鉴定为符合需求的产品后，就会进入到安装阶段，这一阶段包括了在客户站点进行系统或产品的安装和使用，这可以通过互联网或者物理媒介进行，通常交付使用的产品都带有正式的版本号，这为今后的产品升级提供了便利。
6.维护：这一阶段发生在安装之后，包括了对整个系统或某个组件进行修改以改变属性或者提升性能，这些修改可能源于客户的需求变化或者系统使用中没有覆盖到的缺陷，通常，在维护阶段对产品的修改都会被记录下来并产生新的发布版本（称作“维护版本”并伴随升级了的版本号）以确保客户可以从升级中获益。
优势
上述的瀑布模型为软件开发人员提供了众多优势，首先，这个阶段性的软件开发模型规定了以下规则：每个阶段都有指定的起点和终点，过程最终可以被客户和开发者识别（通过使用里程碑），在编写第一行代码之前充分强调了需求和设计，这避免了时间的浪费以及跳票的风险，同时还可以尽可能地保证实现客户的预期需求。
提取需求和设计提高了产品质量，因为在设计阶段捕获并修正可能存在的漏洞要比测试阶段容易很多，毕竟在组件集成之后来追踪特定的错误要复杂很多。最后，因为前两个阶段生成了规范的说明书，当团队成员分散在不同地点的时候，瀑布模型可以帮助实现有效的知识传递。
缺点
除了看上去很明显的这些优势，瀑布模型近来也受到了很多批评，最突出的一点是围绕需求分析的，通常客户一开始并不知道他们需要的是什么，而是在整个项目进程中通过双向交互不断明确的；而瀑布模型是强调捕获需求和设计的，但在这种情况下，现实世界的反复无偿就显得瀑布模型有些不切实际了。
除此以外，即使给定了客户需求，根据这些需求在一定的精确性范围内（瀑布模型所建议的）估算时间和成本是非常困难的。因此，建议在客户需求可以在最初阶段明确的情况下并且相对稳定的项目中使用瀑布模型。
另外的批评指出瀑布模型还假定设计可以被转换为真实的产品，这往往导致开发者在工作时陷入困境，通常，看上去合理可行的设计方案在现实中往往代价昂贵或者异常艰难，从而需要重新设计，这样就破坏了传统瀑布模型中清晰的阶段界限。
有些批评还指出瀑布模型暗示了清晰的分工，将参与开发的人员分为“设计师”、“程序员”和“测试员”，但是在现实中，这样的分工对于软件公司而言既不现实也没有效率。
客户需求
尽管瀑布模型招致了很多批评，但是它对很多类型的项目而言依然是有效的，如果正确使用，可以节省大量的时间和金钱。对于您的项目而言，是否使用这一模型主要取决于您是否能理解客户的需求以及在项目的进程中这些需求的变化程度，对于经常变化的项目而言，瀑布模型毫无价值，对于这种情况，您可以考虑其他的架构来进行项目管理，比如名为螺旋模型（spiral model）的方法，当然，这是另外一码事了，也许我们以后会讲到这些方法。
责任编辑：张琎
查看本文国际来源 | 
