瀑布模型

瀑布模型
Waterfall Model
简介
最早出现的软件开发模型是1970年W·Royce 最早出现的软件开发模型是 年 提出的瀑布模型 。 直到80年代早期 年代早期， 直到 年代早期，它一直是唯一被广泛采用的 软件开发模型。 软件开发模型。 该模型给出了固定的顺序，将生存期活动从上 该模型给出了固定的顺序， 一个阶段向下一个阶段逐级过渡，如同流水下 一个阶段向下一个阶段逐级过渡， 最终得到所开发的软件产品，投入使用。 泻，最终得到所开发的软件产品，投入使用。
缺点
通常客户一开始并不知道他们需要的是什么， 通常客户一开始并不知道他们需要的是什么，而是在整个项目进 程中通过双向交互不断明确的； 程中通过双向交互不断明确的；而瀑布模型是强调捕获需求和设 计的，但在这种情况下， 计的，但在这种情况下，现实世界的反复无偿就显得瀑布模型有 些不切实际了。 些不切实际了。 除此以外，即使给定了客户需求， 除此以外，即使给定了客户需求，根据这些需求在一定的精确性 范围内（瀑布模型所建议的）估算时间和成本是非常困难的。 范围内（瀑布模型所建议的）估算时间和成本是非常困难的。因 此，建议在客户需求可以在最初阶段明确的情况下并且相对稳定 的项目中使用瀑布模型。 的项目中使用瀑布模型。 另外的批评指出瀑布模型还假定设计可以被转换为真实的产品， 另外的批评指出瀑布模型还假定设计可以被转换为真实的产品， 这往往导致开发者在工作时陷入困境，通常， 这往往导致开发者在工作时陷入困境，通常，看上去合理可行的 设计方案在现实中往往代价昂贵或者异常艰难， 设计方案在现实中往往代价昂贵或者异常艰难，从而需要重新设 这样就破坏了传统瀑布模型中清晰的阶段界限。 计，这样就破坏了传统瀑布模型中清晰的阶段界限。 有些批评还指出瀑布模型暗示了清晰的分工， 有些批评还指出瀑布模型暗示了清晰的分工，将参与开发的人员 分为“设计师” 程序员” 测试员” 但是在现实中， 分为“设计师”、“程序员”和“测试员”，但是在现实中，这 样的分工对于软件公司而言既不现实也没有效率。 样的分工对于软件公司而言既不现实也没有效率。
各个ຫໍສະໝຸດ Baidu段的说明
1.需求分析：虽然是第一步，但是这一步至关 需求分析：虽然是第一步， 需求分析 重要， 重要，因为它包含了获取客户需求与定义的信 息，以及对需要解决的问题所能达到的最清晰 的描述。 的描述。分析包含了理解客户的商业环境与约 产品必需实现的功能， 束，产品必需实现的功能，产品必需达到的性 能水平，以及必需实现兼容的外部系统。 能水平，以及必需实现兼容的外部系统。 在这一阶段所使用的技术包括采访客户、 在这一阶段所使用的技术包括采访客户、使用 案例和软件特色的“购物清单”。分析阶段的 案例和软件特色的“购物清单” 结果通常是一份正式的需求说明书， 结果通常是一份正式的需求说明书，这也是下 一阶段的起始信息资料。 一阶段的起始信息资料。
6.维护：这一阶段发生在安装之后，包括了对 维护：这一阶段发生在安装之后， 维护 整个系统或某个组件进行修改以改变属性或者 提升性能， 提升性能，这些修改可能源于客户的需求变化 或者系统使用中没有覆盖到的缺陷，通常， 或者系统使用中没有覆盖到的缺陷，通常，在 维护阶段对产品的修改都会被记录下来并产生 新的发布版本（称作“维护版本” 新的发布版本（称作“维护版本”并伴随升级 了的版本号）以确保客户可以从升级中获益。 了的版本号）以确保客户可以从升级中获益。
优势
每个阶段都有指定的起点和终点， 每个阶段都有指定的起点和终点，过程最终可以被客 户和开发者识别（通过使用里程碑）， ），在编写第一行 户和开发者识别（通过使用里程碑），在编写第一行 代码之前充分强调了需求和设计， 代码之前充分强调了需求和设计，这避免了时间的浪 费以及跳票的风险， 费以及跳票的风险，同时还可以尽可能地保证实现客 户的预期需求。 户的预期需求。 提取需求和设计提高了产品质量， 提取需求和设计提高了产品质量，因为在设计阶段捕 获并修正可能存在的漏洞要比测试阶段容易很多， 获并修正可能存在的漏洞要比测试阶段容易很多，毕 竟在组件集成之后来追踪特定的错误要复杂很多。 竟在组件集成之后来追踪特定的错误要复杂很多。最 因为前两个阶段生成了规范的说明书， 后，因为前两个阶段生成了规范的说明书，当团队成 员分散在不同地点的时候， 员分散在不同地点的时候，瀑布模型可以帮助实现有 效的知识传递。 效的知识传递。
缺陷
在项目开始的时候， 在项目开始的时候，用户常常难以清楚地给出所有需 用户与开发人员对需求理解存在差异。 求；用户与开发人员对需求理解存在差异。 实际的项目很少按照顺序模型进行。 实际的项目很少按照顺序模型进行。 缺乏灵活性： 缺乏灵活性：因为瀑布模型确定了需求分析的绝 对重要性， 对重要性，但是在实践中要想获得完善的需求说明是 非常困难的，导致“阻塞状态” 反馈信息慢， 非常困难的，导致“阻塞状态”。反馈信息慢，开发 周期长。 周期长。 虽然存在不少缺陷，瀑布模型经常被嘲笑为“ 虽然存在不少缺陷，瀑布模型经常被嘲笑为“旧 式的” 但是在需求被很好地理解的情况下， 式的”，但是在需求被很好地理解的情况下，仍然是 一种合理的方法。 一种合理的方法。
2.设计：这一步包括了“定义硬件和软件架构、组件、 设计：这一步包括了“定义硬件和软件架构、组件、 设计 模块、 模块、界面和数据等来满足指定的需求 (Wikipedia)。”它包括了硬件和软件架构的定义， 。 它包括了硬件和软件架构的定义， 确定性能和安全参数，设计数据存储容器和限制， 确定性能和安全参数，设计数据存储容器和限制，选 择集成开发环境（ 择集成开发环境（IDE）和编程语言，并指定异常处 ）和编程语言， 理、资源管理和界面连接性的策略。 资源管理和界面连接性的策略。 这一阶段还强调了用户接口的设计， 这一阶段还强调了用户接口的设计，包括与浏览和可 用性相关的问题， 用性相关的问题，这一阶段的输出结果是一份或多份 设计说明书，这些说明书将在下一阶段使用。 设计说明书，这些说明书将在下一阶段使用。
3.实现：这一步包含了根据设计说明书来构建产品， 实现：这一步包含了根据设计说明书来构建产品， 实现 通常，这一阶段是由开发团队来执行的， 通常，这一阶段是由开发团队来执行的，开发团队包 括了程序员、界面设计师和其他的专家， 括了程序员、界面设计师和其他的专家，他们使用的 工具包括编译软件、调试软件、 工具包括编译软件、调试软件、解释软件和媒体编辑 软件。 软件。 这一阶段将生成一个或多个产品组件， 这一阶段将生成一个或多个产品组件，它们是根据每 一条编码标准而编写的，并且经过了调试、 一条编码标准而编写的，并且经过了调试、测试并进 行集成以满足系统架构的需求。 行集成以满足系统架构的需求。对于大型开发团队而 我建议使用版本控制工具来追踪代码树的变化， 言，我建议使用版本控制工具来追踪代码树的变化， 这样在出现问题的时候可以还原以前的版本。 这样在出现问题的时候可以还原以前的版本。
客户需求
尽管瀑布模型招致了很多批评， 尽管瀑布模型招致了很多批评，但是它对很多 类型的项目而言依然是有效的，如果正确使用， 类型的项目而言依然是有效的，如果正确使用， 可以节省大量的时间和金钱。 可以节省大量的时间和金钱。对于您的项目而 言，是否使用这一模型主要取决于您是否能理 解客户的需求以及在项目的进程中这些需求的 变化程度，对于经常变化的项目而言， 变化程度，对于经常变化的项目而言，瀑布模 型毫无价值， 型毫无价值，
4.测试：在这一阶段，独立的组件和集成后的组件都 测试：在这一阶段， 测试 将进行系统性验证以确保没有错误并且完全符合第一 阶段所制定的需求。 阶段所制定的需求。一个独立的质量保证小组将定义 测试实例” “测试实例”来评估产品是完全实现了需求还是只有 部分满足。 部分满足。 有三种测试方法可以使用： 有三种测试方法可以使用：对独立的代码模块进行单 元测试；对集成产品进行系统测试； 元测试；对集成产品进行系统测试；以及客户参与的 验收测试。如果发现了缺陷， 验收测试。如果发现了缺陷，将会对问题进行记录并 向开发团队反馈以进行修正。在这一阶段， 向开发团队反馈以进行修正。在这一阶段，还有产品 文档会经过准备、评估并发布，比如用户手册等。 文档会经过准备、评估并发布，比如用户手册等。
特点： 特点：
阶段间具有顺序性和依赖性。 阶段间具有顺序性和依赖性。 推迟程序的物理实现。 推迟程序的物理实现。 质量保证：每个阶段必须完成规定的文档；每个阶段结束前完成文档审查,及 质量保证：每个阶段必须完成规定的文档；每个阶段结束前完成文档审查 及 早改正错误。 早改正错误。 易于组织，易于管理：因为你可以预先完成所有计划。 易于组织，易于管理：因为你可以预先完成所有计划。 是一种严格线性的、按阶段顺序的、逐步细化的过程模型（开发模式） 是一种严格线性的、按阶段顺序的、逐步细化的过程模型（开发模式） 适用场合： 适用场合： 当有一个稳定的产品定义和很容易被理解的技术解决方案时， 当有一个稳定的产品定义和很容易被理解的技术解决方案时，纯瀑布模型特 别合适。 别合适。 当你对一个定义得很好的版本进行维护或将一个产品移植到一个新的平台上， 当你对一个定义得很好的版本进行维护或将一个产品移植到一个新的平台上， 瀑布模型也特别合适。 瀑布模型也特别合适。 对于那些容易理解但很复杂的项目，采用纯瀑布模型比较合适， 对于那些容易理解但很复杂的项目，采用纯瀑布模型比较合适，因为可以用 顺序方法处理问题。 顺序方法处理问题。 在质量需求高于成本需求和进度需求的时候，它尤为出色。 在质量需求高于成本需求和进度需求的时候，它尤为出色。 当开发队伍的技术力量比较弱或者缺乏经验时，瀑布模型更为适合。 当开发队伍的技术力量比较弱或者缺乏经验时，瀑布模型更为适合。
在瀑布模型中， 在瀑布模型中，软件开发的各项活动严格按照 线性方式进行， 线性方式进行，当前活动接受上一项活动的工 作结果，实施完成所需的工作内容。 作结果，实施完成所需的工作内容。当前活动 的工作结果需要进行验证，如果验证通过， 的工作结果需要进行验证，如果验证通过，则 该结果作为下一项活动的输入， 该结果作为下一项活动的输入，继续进行下一 项活动，否则返回修改。 项活动，否则返回修改。
5.安装：在产品通过测试并且被鉴定为符合需 安装： 安装 求的产品后，就会进入到安装阶段， 求的产品后，就会进入到安装阶段，这一阶段 包括了在客户站点进行系统或产品的安装和使 这可以通过互联网或者物理媒介进行， 用，这可以通过互联网或者物理媒介进行，通 常交付使用的产品都带有正式的版本号， 常交付使用的产品都带有正式的版本号，这为 今后的产品升级提供了便利。 今后的产品升级提供了便利。
瀑布式开发方法适合软件需求非常明确、 瀑布式开发方法适合软件需求非常明确、设计 方案确定、编码环境熟悉 方案确定、 等所有阶段都有较大把握的软件开发活动。 等所有阶段都有较大把握的软件开发活动。
存在的问题
（1） 各个阶段的划分完全固定，阶段之间产 ） 各个阶段的划分完全固定， 生大量的文档，极大地增加了工作量； 生大量的文档，极大地增加了工作量； （2） 由于开发模型是线性的，用户只有等到 ） 由于开发模型是线性的， 整个过程的末期才能见到开发成果， 整个过程的末期才能见到开发成果，从而增加 了开发的风险； 了开发的风险； （3） 早期的错误可能要等到开发后期的测试 ） 阶段才能发现，进而带来严重的后果。 阶段才能发现，进而带来严重的后果。