软件过程模型
为了改变软件开发的混乱状况，使软件开发更加有序。
瀑布模型
又称为经典生命周期，它提出了一个系统的，顺序的软件开发方法，从用户需求规格说明开始，通过策划，建模，构建和部署的过程，最终提供完整的软件支持。这种模型是将软件生存周期各个活动规定为依线性顺序连接的若干阶段的模型。它包括问题定义、可行性研究、需求分析、概要设计、详细设计、编码、测试和维护。它规定了由前至后、相互衔接的固定次序，恰如奔流不息拾级而下的瀑布。
图1.1所示的是按照传统的瀑布模型生存周期的各阶段出现的顺序，大致介绍了它的全过程。
图2.1所示为传统的瀑布模型。
如图2-1所示：（另一本书内容）
按照传统的瀑布模型来开发软件，有如下几个特点。
（1）阶段的顺序性和依赖性
这个特点有两重含义：
必须等前一阶段的工作完成之后，才能开始后一阶段的工作；前一阶段的输出文档就是后一阶段的输入文档。因此，只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。
但是，万一在生命周期某一阶段发现了问题，很可能需要追溯到在它之前的一些阶段，必要时还要修改前面已经完成的文档。然而，在生命周期后期改正早期阶段造成的问题，需要付出很高的代价。这就好像水已经从瀑布顶部流泻到底部，再想使它返回到高处需要付出很大能量一样。
（2）推迟实现的观点
对于中、大规模软件项目来说，往往是编码工作开始得越早，最终完成开发工作所需要的时间就越长。这是因为前一阶段工作做得不够扎实，有缺陷，在这种情况下过早地考虑编写程序，常常造成大量返工，有时甚至给开发人员带来灾难性的后果，造成无法弥补的局面。
瀑布模型在编码之前是分析阶段和设计阶段。这两个阶段的任务是考虑目标系统的逻辑模型，不涉及软件的物理实现。
（3）质量保证的观点
软件工程的重要目标是优质、高产。为了保证所开发的软件的质量，在瀑布模型的各个阶段都应该坚持以下两点重要的做法。
每一个阶段都必须完成所规定的相应文档，没有交出合格文档就是没有完成该阶段的任务。完整、准确地规范文档不仅是软件开发时期各类人员之间相互通信的媒介，也是运行时期对软件进行维护的重要依据。每一个阶段结束之前都必须对已完成的文档进行评审，以便尽早发现问题，纠正错误。从图1.2可以看出，越是早期阶段犯下的错误，暴露出来的时间就越晚，排除故障改正错误所需付出的代价就越高。因此，及时审查是保证软件质量降低软件开发成本的重要措施。
（4）存在的问题
按照瀑布模型来开发软件，只有当分析员能够做出准确的需求分析时，才能得到预期的正确结果。它是一种理想的线性开发模式，缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。
优点：
1.可强迫开发人员采用规范的方法（如结构化技术）；
2.严格地规定了每个阶段必须提交的文档；
3.要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
缺点：
各个阶段的划分完全固定，阶段之间产生大量的文档，增加了开发工作量；由于开发过程是线性的，用户只有在整个过程结束时，才能看到开发成果；开发过程中间，很难响应用户的变更要求；早期的错误，也要等到开发后期的测试阶段才能发现，这样会产生严重的后果。
瀑布模型仅适合于在软件需求比较明确、开发技术比较成熟、工程管理比较严格的场合下使用。
瀑布模型的一个变体称为V模型。
如图4-2所示，V模型描述了质量保证动作同沟通，建模相关动作以及早期构建相关的动作之间的关系。随着软件团队工作沿着V模型左侧步骤向下推进，基本问题需求逐步细化，形成了对问题及解决方案的详尽且技术性的描述。一旦编码结束，团队沿着V模型右侧的步骤向上推进工作，其本质上是执行了一系列测试（质量保证动作），这些测试验证了团队沿着V模型左侧步骤向下推进过程中所生成的每个模型。实际上，经典生命周期模型和V模型没有本质区别，V模型提供一种将验证和确认动作应用于早期软件工程工作中的直观方法。
