软件开发的瀑布模型
    软件工程强调规范化，所以软件开发方法学均需提供软件开发处理模型，它具体地描述软件开发做些什么工作；如何进行；由谁进行；用什么方式来实现；何时结束。
    最早提出、并且使用最广的处理模型称之为瀑布模型，是1976年由Bohm提出。它将软件生命周期分为：软件定义（计划）、软件开发和软件维护（运行）三个时期组成，每个时期又进一步划分为若干个阶段。
    软件定义时期可分为三个阶段：问题定义、可行性研究和需求分析。
    开发时期可分为：总体设计、详细设计、编码和单元测试、综合测试四个阶段.

瀑布模型的特点
1）连续性：前一阶段完成后，后一阶段工作才能开始，前一阶段输出的文档是后一阶段的输入文档。另外，个阶段之间不存在反馈的关系。这使得该模型好似瀑布一样，故称之为瀑布模型。
2）该模型描述了软件开发如何进行：定义了每个阶段的每件事情，并且符合实际的开发过程。
3）严格的质量管理要求：由于该模型不存在反馈，如果前面阶段工作存在错误不能及时发现，将造成极大的损失。所以每个阶段后，对该阶段提交的文档均进行严格的技术审查和管理复审。（技术审查是从技术的角度，对该阶段开发出的产品进行检验。管理复审是在每个阶段结束时，对项目成本、进度、实际的费用及投资回收前景从管理角度进行复查。）
4）连续无反馈：意味着一个前提条件，即后一阶段的工作是在假定前一阶段工作是正确无误的前提条件。因此，该模型不适合需求不易确定或多变的软件项目的开发。该模型适合于小项目，而不适合于大项目。因为大项目在软件开发的前期阶段不可能了解项目很多的细致情况，从而会引起需求变化。

目前最常见的生命周期是“瀑布”模型（结构化）。它是在60年代末“软件危机”后出现的第一个生命周期模型。如下所示。

分析 ----- 设计 ----- 编码 ----- 测试 ------ 维护

如图所示，瀑布式生命周期的开发过程是顺序行进的；活动流向基本是单向的。它假设开发者在开发初期对系统的了解足够清楚。不幸的是，任何软件开发活动都不可避免地要涉及大量迭代过程，无论你事先是否安排。好的设计人员指的是那些能同时在抽象的层面和具体的细节上进行工作的实践家。总的来说，瀑布式生命周期的缺点表现在三个方面：<1> 后期的变化、迭代、改动困难 <2> 不支持重用 <3> 没有一个联系各个阶段的统一模型。

评论