瀑布模型
定义与分类
1970年温斯顿.罗伊斯提出了著名的“瀑布模型”(也称经典生命周期模型),直到80年代早期,它一直是唯一被广泛采用的软件开发模型
瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落
瀑布模型是最早出现的软件开发模型,在软件工程中占有重要的地位,它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入,利用这一输入实施该项活动应完成的内容给出该项活动的工作成果,并作为输出传给下一项活动
从本质来讲,它是一个软件开发架构,开发过程是通过一系列阶段顺序展开的,从系统需求分析开始直到产品发布和维护,每个阶段都会产生循环反馈,因此,如果有信息未被覆盖或者发现了问题,那么最好 “返回”上一个阶段并进行适当的修改,开发进程从一个阶段“流动”到下一个阶段,这也是瀑布开发名称的由来
对于经常变化的项目而言,瀑布模型毫无价值
V模型(变种)
特点
- 线性模型
- 阶段间具有顺序性和依赖性
该阶段具有两重含义
必须等前一阶段的工作完成后,才能开始后一阶段的工作
前一阶段的输出文档就是后一阶段的输入文档,因此只有前一阶段的输出文档正确, 后一阶段的工作才能获得正确的结果
- 推迟实现
对于规模较大的软件项目来说,往往编码开始的越早,最终完成开发所需时间越长。因为前面阶段的工作没做或做的不扎实,过早地考虑进行程序实现,往往导致大量返工,有时甚至发生无法弥补的问题
瀑布模型在编码之前设置了系统分析与系统设计的各个阶段,分析与设计阶段的基本任务规定,在这两个阶段主要考虑目标系统的逻辑模型,不涉及软件的物理实现
清楚的区分逻辑设计与物理设计,尽可能推迟程序的物理实现,是按照瀑布模型开发软件的一条重要的指导思想
- 以文档为驱动
瀑布模型是文档驱动的模型,遵守这个约束可使软件维护变得比较容易一些,从而显著降低软件预算
优点
- 为项目提供了按阶段划分的检查点
- 当前一阶段完成后,只需关注后续阶段
- 可在迭代模型中应用瀑布模型
缺点
- 增加工作量(大量文档)
- 开发风险大:线性模型
- 早期错误发现晚,由于开销的逐步升级问题,它不希望存在早期阶段的反馈
- 不适合需求模糊或需求经常变动的系统
- 在一个系统完成以前,它无法预测一个新系统引入一个机构的影响
适用场合
系统需求明确且稳定,技术成熟,工程管理严格,如军工、航天、医疗
相关ppt可参见瀑布模型