瀑布模型&快速原型模型

一、瀑布模型

1.1 什么是瀑布模型

瀑布模型将软件生命周期划分为软件计划、需求分析、软件设计、程序编码、软件测试、运行维护等基本活动，并且规定了他们自上而下、相互衔接的固定顺序，如同瀑布流水，逐级下落。

瀑布模型是最早出现的软件开发模型，在软件工程中占有特别重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。

对于经常变化的项目而言，瀑布模型毫无价值。

1.2 特点

1、阶段间具有顺序性和依赖性

• 必须等前一阶段的工作完成之后，才能开始下一阶段的工作
• 前一阶段的输出文档就是后一阶段的输入文档，因此只有前一阶段的输出文档完全正确，后一阶段的工作才能获得正确的结果

2、推迟实现的观点

对于规模比较大的软件项目来说，往往编码阶段开始的越早，最终完成开发所需时间越长。因为前面阶段的工作没做或做的不扎实，过早地考虑进行程序实现，往往导致大量的返工，有时甚至发生无法弥补的问题。

瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，需求分析与软件设计阶段的基本任务规定，在这两个阶段主要考虑的目标系统的逻辑模型，不涉及软件的物理实现。

清楚的区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要的指导思想。

3、质量保证的观点

为了保证所开发的软件的质量，在瀑布模型的每一个阶段都应坚持两个重要的做法：

• 1、每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。
• 2、每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。

传统的瀑布模型，过于理想化，一旦在后面的阶段发现前面的阶段出现问题，没有办法进行任何的修改。所以后人对传统的瀑布模型进行了一些改进，加上了反馈环。如图所示（图中实线箭头表示开发过程，虚线箭头表示维护过程），当在后面阶段发现前面阶段的错误时，需要沿着图中左侧的反馈线返回前面的阶段，修正前面阶段的产品后再回来继续完成后面阶段的任务。

瀑布模型是文档驱动的模型，遵守这个约束可以使得软件维护变得容易一些，从而显著降低软件预算。

1.3 优缺点

优点：

• 为项目提供了按阶段划分的检查点
• 当前一阶段完成之后，只需要关注后续阶段
• 可在迭代模型中应用瀑布模型

缺点:

• 不适合需求模糊或需求经常变动的系统
• 由于开销的逐步升级问题，它不希望存在早期阶段的反馈
• 在一个系统完成以前，它无法预测一个新系统引入一个机构的影响
• 在用户可能需要较长等待时间来获取一个可供使用的系统，也许会给用户的信任程度带来影响和打击
• 最终产品往往反映用户的初始需求，而不是最终需求

1.4 客户需求

对于项目而言，是否使用瀑布模型主要取决于是否能理解客户的需求以及在项目进程中这些需求的变化程度。对于经常变化的项目而言，瀑布模型将毫无价值，可以考虑使用其他的架构来进行项目管理，比如螺旋模型、敏捷开发模型等等。

瀑布模型强调文档的作用，并且要求每个阶段都要仔细验证。但是瀑布模型的线性过程太过于理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要的问题在于：
1、各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2、由于开发模型是线性的，用户只有等到整个过程的末期，才能看到开发的成果，从而增加了开发的风险。
3、早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果，公司很难承担。

按照瀑布模型的阶段划分，软件测试可以分为单元测试、集成测试、系统测试。

二、快速原型模型

2.1 什么是快速原型模型

快速模型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。
快速原型模型是增量模型的另一种形式，在开发真实系统之前，迅速简历一个可以运行的软件原型，以便理解和澄清问题，在该原型的基础上，逐渐完成整个系统的开发工作。

它允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速设计开发出软件系统的原型，该原型向用户展示待开发软件的全部或部分功能和性能；用户对该原型进行测试评定，给出具体的改进意见以丰富、细化软件需求。开发人员据此对软件进行修改、完善，直至用户满意、认可之后，进行软件的完整实现及测试、维护。

2.2 优缺点

优点

• 克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险
• 适合预先不能确切定义需求的软件系统的开发

缺点

• 所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。
• 使用前提是要有一个展示性的产品原型，一定程度上可能会限制开发人员的创新。

2.3 快速原型模型的思想产生、原理及运用方式

1、思想产生

在需求分析阶段得到完全、一致、准确、合理的需求说明十分困难。

获得一组基本需求说明后，就快速地使其实现，通过原型反馈，加深对系统的理解满足用户基本要求，使用户在试用后对需求说明进行补充和精确化，从而获得合理完整、现实可行的需求说明。

再把快速原型思想用到软件开发的其他阶段，向软件开发的全过程扩展。

先用相对少的成本、较短的周期开发一个简单的，但是可以运行的系统原型向用户演示或让用户试用，以便及早澄清并检验一些主要设计策略，在此基础上再开发实际的软件系统。

2、原理

利用原型辅助软件开发

经过简单快速分析，快速实现一个原型，用户与开发者在试用原型过程中加强通信和反馈，通过反复评价和改进原型，减少误解，弥补漏洞，最终提高软件质量。

3、运用方式

由于运用原型的目的和方式不同，在使用原型时也采取不同的策略

• 抛弃策略：将原型用于开发过程的某个阶段，促使该阶段的开发结果更加完整、准确、一致、可靠，该阶段结束之后，原型随之作废。探索型和实验型就是采用此策略的。
• 附加策略：将原型用于开发的全过程，原型由最基本的核心开始，逐步增加新的功能和新的需求，反复修改、反复扩充，最后发展为用户满意的最终系统，演化型快速原型就是采用此策略。

采用何种形式、何种策略运用快速原型主要取决于软件项目的特点、可供支持的原型开发工具和技术等，根据实际情况的特点决定。

2.4 类型

在软件开发中，原型是软件的一个早期可运行的版本，它反映最终系统的部分重要特性

探索型

这种原型目的是要弄清对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性

实验型

这种原型用于大规模开发和实现之前，考核方案是否合适，规格说明是否可靠

进化型

这种原型的目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统

2.5 开发步骤

1、快速分析

在分析人员与用户密切配合下，迅速确定系统的基本需求，根据原型需要体现的特征描述基本需求以满足开发原型的需要

2、构造原型

在快速分析的基础上，根据基本需求说明尽快实现一个可行的系统

要求具有强有力的软件工具的支持，并忽略最终系统在某些细节上的要求，主要考虑原型系统能够充分反映所要评价的特性

3、运行原型

发现问题，消除误解，开发者与用户充分协调

4、评价原型

在运行的基础上，考核评价原型的特性，分析运行效果是否满足用户的愿望，纠正过去交互中的误解与分析中的错误，增添新的要求，并满足因环境变化或用户的新想法引起的系统要求变动，提出全面的修改意见

5、修改

根据评价原型的活动结果进行修改

若原型未满足需求说明的要求，说明对需求说明存在不一致的理解或实现方案不够合理，根据明确的要求迅速修改原型

快速原型模型不带反馈环，软件产品的开发基本上是线性顺序进行的

快速原型的本质是"快速"。开发人员应尽可能地建造出原型系统，以加速软件开发过程，节约软件开发成本

原型的用途是获知用户的真正需求，一旦需求确定了，原型将被抛弃

三、增量模型

3.1 什么是增量模型