瀑布模型(Waterfall Model) 是一个软件生命周期模型,开发过程是通过设计一系列阶段顺序展开的,从系统需求分析开始直到产品发布和维护,项目开发进程从一个阶段“流动”到下一个阶段。
优缺点
优点
可强迫开发人员采用规范的方法(如结构化技术);严格地规定了每个阶段必须提交的文档;要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
缺点
瀑布模型是由文档驱动,在可运行的软件产品交付给用户之前,用户只能通过文档来了解产品是什么样的。瀑布模型几乎完全依赖于书面的规格说明,很可能导致最终开发出的软件产品不能真正满足用户的需要。也不适合需求模糊的系统。
瀑布模型核心思想是按工序将问题化简,将功能的实现与设计分开,便于分工协作,即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。
特点
(1) 阶段间具有顺序性和依赖性
必须等前一阶段的工作完成之后,才能开始后一阶段的工作。前一阶段的输出文档就是后一阶段的输入文档。
(2) 推迟实现的观点
清楚的区分逻辑设计与物理设计,尽可能推程序的物理实现,是因为编码之前阶段的工作没做或做得不扎实,过早地考虑进行程序实现,往往导致大量返工,有时甚至发生无法弥补的问题,带来灾难性的后果。实践也表明,对于规模较大的软件项目来说,往往编码开始得越早最终完成开发工作所需要的时间反而越长。
(3) 质量保证的观点
每个阶段都必须完成规定的文档,没有交出合格的文档就是没有完成该阶段的任务。
每个阶段结束前都要对所完成的文档进行评审,以便尽早发现问题,改正错误。
- 加入迭代过程的瀑布模型
原因
传统的瀑布模型过于理想化,人在工作过程中不可能不犯错误。
特点
当后面阶段发现前面阶段的错误时,需要沿图中左侧的反馈线返回前面的阶段,修正前面阶段的产品之后再回来继续完成后面阶段的任务。