软件工程--瀑布模型特点详解

瀑布模型

在20世纪80年代之前，瀑布模型一直是唯一被广泛采用的生命周期模型，现在它仍然是软件工程中应用得最广泛的过程模型。传统软件工程方法学的软件过程，基本上可以用瀑布模型来描述。

如下图所示为传统的瀑布模型。按照传统的瀑布模型开发软件，有下述的几个特点：

1. 阶段间具有顺序性和依赖性
阶段间具有顺序性和依赖性，这个特点有两重含义：

必须等前一阶段的工作完成之后，才能开始后一阶段的工作；
前一阶段的输出文档就是后一阶段的输入文档，因此，只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。

2. 推迟实现的特点
缺乏软件工程实践经验的软件开发人员，接到软件开发任务以后常常急于求成，总想尽早开始编写程序。但是，实践表明，对于规模较大的软件项目来说，往往编码开始得越早，最终完成开发工作所需要的时间反而越长。这是因为，前面阶段的工作没做或做得不扎实，过早地考虑进行程序实现，往往导致大量返工，有时甚至发生无法弥补的问题，带来灾难性后果。

瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，分析与设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。

清楚区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要的指导思想。

3. 质量保证的观点
软件工程的基本目标是优质、高产。为了保证所开发的软件的质量，在瀑布模型的每个阶段都应该坚持两个重要做法。

每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。完整、准确的合格文档不仅仅是软件开发时期各类人员之间相互通信的媒介，也是运行时期对软件进行维护的重要依据。
每个阶段结束前都要对所完成的文档进行评审，以尽早发现问题，改正错误。事实上，越是早期阶段犯下的错误，暴漏出来的时间就越晚，排除故障改正错误所需付出的代价也越高。因此，及时审查，是保证软件质量、降低软件成本的重要措施。

实际中的瀑布模型

传统的瀑布模型过于理想化了，事实上，人在工作过程中不可能不犯错误。在设计阶段可能发现规格说明文档中的错误，而设计上的缺点或错误可能在实现过程中显现出来，在综合测试阶段将发现需求分析、设计或编码阶段的许多错误。因此，实际的瀑布模型是带"反馈环"的，如下图所示（实线箭头表示开发过程，虚线箭头表示维护过程）。

当在后面阶段发现前面阶段的错误时，需要沿图中左侧的反馈线返回前面你的阶段，修正前面阶段的产品之后再回来继续完成后面的阶段的任务。

瀑布模型的优点

可强迫开发人员采用规范的方法（例如，结构化技术）；
严格地规定了每个阶段必须提交的文档；
要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证；

各个阶段产生的文档是维护软件产品时必不可少的，没有文档的软件几乎是不可能的。遵守瀑布模型的文档约束，将使软件维护变得比较容易一些。由于绝大部分软件预算都花费在软件维护上，因此，使软件变得比较容易维护就能显著降低软件预算。可以说，瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型。

瀑布模型的缺点

但是，“瀑布模型是由文档驱动的”这个事实也是它的一个主要缺点。

在可运行的软件产品交付给用户之前，用户只能通过文档来了解产品是什么样的。但是，仅仅通过写在纸上的静态的规格说明，很难全面正确地认识动态的软件产品。而且事实证明，一旦一个用户开始使用一个软件，在他的头脑中关于该软件应该做什么的想法就会或多或少地发生变化，这就使得最初提出的需求变得不完全适用了。

事实上，要求用户不经过实践就提出完整准确的需求，在许多情况下都是不切实际的。总之，由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发的软件产品不能真正满足用户的需要。