瀑布模型软件开发的特征

    (1)阶段间的顺序性和依赖性。在这里，顺序性有两重含义：第一，只有等前一阶段的工作完成以后，后一阶段的工作才能开始：第二，前一阶段的输出文档，就是后一阶段的输入文档。依赖性又同时表明了，只有前一阶段有正确的输出时，后-阶段才可能有正确的结果。因此，如果在生存周期某一阶段出现了问题，往往要追溯到它之前的一些阶段， 必要时还要修改前面已经完成的文档。

    (2)推迟实现的观点。软件开发人员接受任务后，往往急于求成，总想早一点开始编写程序。实践表明，对于大、中型的软件，编码开始得越早，完成所需的时间反而越长。这是因为过早地考虑程序的实现，常常导致大量返工，有时甚至给开发人员带来灾难性的后果。瀑布模型在编码以前安排了分析阶段和设计阶段，并且明确宣布，这两个阶段都只考虑目标系统的逻辑模型，不涉及软件的物理实现。也就是说，直到设计阶段结束，设计人员完成的文档仍然是独立于设备的抽象的逻辑模型。

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

    (3)质量保证的观点。优质与高产是软件工程的重要目标。为了保证质量，瀑布型软件开发在各个阶段坚持了两个重要的做法:

    ①每一阶段都要完成规定的文档。没有完成文档，就认为没有完成该阶段的任务。

    ②每一阶段都要对完成的文档进行复审，以便尽早发现问题，消除隐患。经验表明，越是早期潜伏下来的故障，暴露出来的时间越晚，排除故障所付出的代价也就越高。

    瀑布模型为软件开发和软件维护提供了一种有效的管理图式。根据这一图式制定开发计划、进行成本预算、组织开发力量，以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，从而保证了软件产品及时交付，并达到预期的质量要求。瀑布模型30多年来之所以广为流行，是因为它在消除非结构化软件、降低软件的复杂度、促进软件开发工程化方面起着显著作用。同时，瀑布模型在大量的软件开发实践中也逐渐暴露出它的严重缺点。

    其中最为突出的缺点是该模型缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。这些问题的存在对软件开发会带来严重影响，最终可能导致开发出的软件并不是用户真正需要的软件，并且这一点在开发过程完成后才有所察觉。面对这些情况，无疑需要进行返工或是不得不在维护中纠正需求的偏差。但无论上述哪一种情况都必须付出高额的代价，并将为软件开发带来不必要的损失。为了弥补瀑布模型的不足，近年来已经提出了多种其他模型。