1970年Winston Royce提出了著名的"瀑布模型"，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。不知道大家在不看下文介绍瀑布模型之前是不是已经了解了瀑布模型的具体问题？还没接触过的人就有福啦，可以通过本文学习新的知识。当然，如果你已经了解了相关内容也没事，小编在此文里面重新给大家梳理一遍。
提到“瀑布开发”的时候，小编不知道大家会想到什么。有可能大部分人们可能会联想到尼亚加拉瀑布下要进行房地产开发，然后，设想一下，当您告诉他们实际上瀑布开发是一种包含多个阶段的反复叠代的软件开发模型时，他们会多么惊讶。这篇文章将为您提供一份关于瀑布模型的简要介绍，解释它是什么，应当怎样工作以及可能导致项目失败的原因。
接下来，大家就跟着小编的脚步走吧！
瀑布模型概述
瀑布模型其实并不新，它在1970年前后就已经出现了，但是大部分开发者对瀑布模型只有一个模糊的概念。从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是瀑布开发名称的由来。它包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。
如上图所示，我们可以看到一个开发阶段必须在另一个开发阶段开始之前完成。因此，当从客户引发的所有需求都已经过完整性和一致性分析，并形成需求文档之后，开发团队才能够开始进行系统设计活动。瀑布模型从一种非常高层的角度描述了开发过程中进行的活动，并且提出了要求开发人员经过的事件序列。
这一模型存在很多变体，每种只是在阶段名称上略有区别，但是，总体来讲，瀑布开发模型可以分为六个不同的阶段，其定义如下：
1.需求分析：虽然是第一步，但是这一步至关重要，因为它包含了获取客户需求与定义的信息，以及对需要解决的问题所能达到的最清晰的描述。分析包含了理解客户的商业环境与约束，产品必需实现的功能，产品必需达到的性能水平，以及必需实现兼容的外部系统。
在这一阶段所使用的技术包括采访客户、使用案例和软件特色的“购物清单”。分析阶段的结果通常是一份正式的需求说明书，这也是下一阶段的起始信息资料。
2.设计：这一步包括了“定义硬件和软件架构、组件、模块、界面和数据等来满足指定的需求(Wikipedia)。”它包括了硬件和软件架构的定义，确定性能和安全参数，设计数据存储容器和限制，选择集成开发环境（IDE）和编程语言，并指定异常处理、资源管理和界面连接性的策略。
这一阶段还强调了用户接口的设计，包括与浏览和可用性相关的问题，这一阶段的输出结果是一份或多份设计说明书，这些说明书将在下一阶段使用。
3.实现：这一步包含了根据设计说明书来构建产品，通常，这一阶段是由开发团队来执行的，开发团队包括了程序员、界面设计师和其他的专家，他们使用的工具包括编译软件、调试软件、解释软件和媒体编辑软件。
这一阶段将生成一个或多个产品组件，它们是根据每一条编码标准而编写的，并且经过了调试、测试并进行集成以满足系统架构的需求。对于大型开发团队而言，我建议使用版本控制工具来追踪代码树的变化，这样在出现问题的时候可以还原以前的版本。
4.测试：在这一阶段，独立的组件和集成后的组件都将进行系统性验证以确保没有错误并且完全符合第一阶段所制定的需求。一个独立的质量保证小组将定义“测试实例”来评估产品是完全实现了需求还是只有部分满足。
有三种测试方法可以使用：对独立的代码模块进行单元测试；对集成产品进行系统测试；以及客户参与的验收测试。如果发现了缺陷，将会对问题进行记录并向开发团队反馈以进行修正。在这一阶段，还有产品文档会经过准备、评估并发布，比如用户手册等。
5.安装：在产品通过测试并且被鉴定为符合需求的产品后，就会进入到安装阶段，这一阶段包括了在客户站点进行系统或产品的安装和使用，这可以通过互联网或者物理媒介进行，通常交付使用的产品都带有正式的版本号，这为今后的产品升级提供了便利。
6.维护：这一阶段发生在安装之后，包括了对整个系统或某个组件进行修改以改变属性或者提升性能，这些修改可能源于客户的需求变化或者系统使用中没有覆盖到的缺陷，通常，在维护阶段对产品的修改都会被记录下来并产生新的发布版本（称作“维护版本”并伴随升级了的版本号）以确保客户可以从升级中获益。
明确了瀑布模型开发的六个阶段后，相信您对它的作用及优势劣势有了更大的兴趣了吧！
瀑布模型优势
上述的瀑布模型为软件开发人员提供了众多优势，首先，这个阶段性的软件开发模型规定了以下规则：每个阶段都有指定的起点和终点，过程最终可以被客户和开发者识别（通过使用里程碑），在编写第一行代码之前充分强调了需求和设计，项目开发中涉及到的几乎一切都预先计划，从而便于确定预期的开发成本和开发时间。这避免了时间的浪费以及跳票的风险，同时还可以尽可能地保证实现客户的预期需求。
提取需求和设计提高了产品质量，因为在设计阶段捕获并修正可能存在的漏洞要比测试阶段容易很多，毕竟在组件集成之后来追踪特定的错误要复杂很多。最后，因为前两个阶段生成了规范的说明书，当团队成员分散在不同地点的时候，瀑布模型可以帮助实现有效的知识传递。
瀑布模型缺点
除了看上去很明显的这些优势，瀑布模型近来也受到了很多批评，最突出的一点是围绕需求分析的，通常客户一开始并不知道他们需要的是什么，而是在整个项目进程中通过双向交互不断明确的；而瀑布模型是强调捕获需求和设计的，但在这种情况下，现实世界的反复无偿就显得瀑布模型有些不切实际了。例如，McCracken和Jackson指出，瀑布模型在系统开发之上强加了一种项目管理结构（McCracken and Jackson 1981）。"主张任何一种生命周期方案（即使它具有各种变种）能够适用于所有的系统开发显然是违背现实的，或者由于假定一个过于简陋的生命周期而显得毫无意义。"
除此以外，即使给定了客户需求，根据这些需求在一定的精确性范围内（瀑布模型所建议的）估算时间和成本是非常困难的。因此，建议在客户需求可以在最初阶段明确的情况下并且相对稳定的项目中使用瀑布模型。
另外的批评指出瀑布模型还假定设计可以被转换为真实的产品，这往往导致开发者在工作时陷入困境，通常，看上去合理可行的设计方案在现实中往往代价昂贵或者异常艰难，从而需要重新设计，这样就破坏了传统瀑布模型中清晰的阶段界限。
有些批评还指出瀑布模型暗示了清晰的分工，将参与开发的人员分为“设计师”、“程序员”和“测试员”，但是在现实中，这样的分工对于软件公司而言既不现实也没有效率。
客户对瀑布模型的需求
尽管瀑布模型招致了很多批评，但是它对很多类型的项目而言依然是有效的，如果正确使用，可以节省大量的时间和金钱。对于您的项目而言，是否使用这一模型主要取决于您是否能理解客户的需求以及在项目的进程中这些需求的变化程度，对于经常变化的项目而言，瀑布模型毫无价值，对于这种情况，您可以考虑其他的架构来进行项目管理，比如名为螺旋模型（spiralmodel）的方法，当然，这是另外一码事了，也许我们以后会讲到这些方法。
注意：在部署瀑布开发模式之前你必须仔细评估自己所处的环境和条件。如果客户希望在开发工作开始之后加入进来或者你要处理很多未知的问题，那么你或许最好采用一种更具重复性的开发过程。
小编结语
瀑布模型产生于硬件领域，它是从制造业的角度看待软件开发的，因此，软件是一个创造的过程，而不是一个制造的过程。它通常包含不同的尝试、开发和评估原型、评价需求的可行性、比较若干种设计以及从失败的教训中学习，从而最终决定问题令人满意的解决方案。
文章对瀑布模型的介绍就到这里啦！您是否充分了解瀑布模型了呢？如果各位还有什么疑惑或者对这方面有兴趣的，您可以在编程学习网教育进行咨询，此外，还有更多精彩文章放送！
