android 瀑布流_软件工程过程模型之瀑布模型

有时候，当从沟通到部署都采用合理的线性工作流方式的时候，可以清楚地理解问题的需求。这种情况通常发生在需要对一个已经存在的系统进行明确定义的适应性调整或是增强的时候(比如政府修改了法规，导致财务软件必须进行相应修改);也可能发生在很少数新的开发工作上，但是需求必须是准确定义和相对稳定的。

瀑布模型(waterfall model)又称为经典生命周期(classic life cycle)，它提出了一个系统的、顺序的软件开发方法，从用户需求规格说明开始，通过策划、建模、构建和部署的过程，最终提供完整的软件支持。

瀑布模型

瀑布模型的一个变体称为V模型(V-model)。V模型描述了质量保证动作同沟通、建模相关动作以及早期构建相关的动作之间的关系。随着软件团队工作沿着V模型左侧步骤向下推进，基本问题需求逐步细化，形成了对问题及解决方案的详尽且技术性的描述。一旦编码结束，团队沿着V模型右侧的步骤向上推进工作，其本质上是执行了一系列测试(质量保证动作)，这些测试验证了团队沿着V模型左侧步骤向下推进过程中所生成的每个模型。实际上，经典生命周期模型和V模型没有本质区别，V模型提供了一种将验证和确认动作应用于早期软件工程工作中的直观方法。

V模型

瀑布模型是软件工程最早的范例。尽管如此，在过去的40多年中，对这一过程模型的批评使它最热情的支持者都开始质疑其有效性。在运用瀑布模型的过程中，人们遇到的问题包括:

1.实际的项目很少遵守瀑布模型提出的顺序。虽然线性模型可以加入迭代，但是它是用间接的方式实现的，结果是，随着项目组工作的推进，变更可能造成混乱。

2.客户通常难以清楚地描述所有的需求。而瀑布模型却要求客户明确需求，这就很难适应在许多项目开始阶段必然存在的不确定性。

3.客户必须要有耐心，因为只有在项目接近尾声的时候，他们才能得到可执行的程序。对于系统中存在的重大缺陷，如果在可执行程序评审之前没有发现，将可能造成惨重损失。

在分析一个实际项目时，Bradac[Bra94]发现，经典生命周期模型的线性特性在某些项目中会导致“阻塞状态”，由于任务之间的依赖性，开发团队的一些成员要等待另一些成员工作完成。事实上，花在等待上的时间可能超过花在生产性工作上的时间。在线性过程的开始和结束，这种阻塞状态更容易发生。

目前，软件工作快速进展，经常面临永不停止的变更流，特性、功能和信息内容都会变更，瀑布模型往往并不适合这类工作。尽管如此，在需求已确定的情况下，且工作采用线性的方式完成的时候，瀑布模型是一个很有用的过程模型。