目录
 
一、瀑布模型
 
1.1什么是瀑布模型
 
1.2特点
 
1.3优缺点
 
1.4客户需求
 
二、快速原型模型
 
2.1什么是快速原型模型
 
2.2优缺点
 
2.3快速原型模型的思想产生、原理及运用方式
 
2.4类型
 
2.5开发步骤
 
三、增量模型
 
3.1什么是增量模型
 
3.2特点
 
3.3优缺点
 
3.4作用
 
四、螺旋模型
 
4.1什么是螺旋模型
 
4.2特点
 
4.3优缺点
 
4.4限制条件
 

一、瀑布模型
 
1.1什么是瀑布模型
 
1970年温斯顿.罗伊斯提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型
 
瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落
 
 
瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动
 
从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是瀑布开发名称的由来
 
对于经常变化的项目而言，瀑布模型毫无价值
 
1.2特点
 
1、阶段间具有顺序性和依赖性
 
该阶段具有两重含义
 
必须等前一阶段的工作完成后，才能开始后一阶段的工作
前一阶段的输出文档就是后一阶段的输入文档，因此只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果
2、推迟实现的观点
 
对于规模较大的软件项目来说，往往编码开始的越早，最终完成开发所需时间越长。因为前面阶段的工作没做或做的不扎实，过早地考虑进行程序实现，往往导致大量返工，有时甚至发生无法弥补的问题
 
瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，分析与设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现
 
清楚的区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要的指导思想
 
3、质量保证的观点
 
为了保证所开发的软件的质量，在瀑布模型的每一个阶段都应坚持两个重要做法
 
每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务
每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误
传统的瀑布模型过于理想化，实际的瀑布模型是带"反馈环"的。如图所示（图中实线箭头表示开发过程，虚线箭头表示维护过程），当在后面阶段发现前面阶段的错误时，需要沿图中左侧的反馈线返回前面的阶段，修正前面阶段的产品后再回来继续完成后面阶段的任务
 
 
瀑布模型是文档驱动的模型，遵守这个约束可使软件维护变得比较容易一些，从而显著降低软件预算
 
 
1.3优缺点
 
优点：
 
为项目提供了按阶段划分的检查点
当前一阶段完成后，您只需要去关注后续阶段
可在迭代模型中应用瀑布模型
缺点：
 
不适合需求模糊或需求经常变动的系统
由于开销的逐步升级问题，它不希望存在早期阶段的反馈
在一个系统完成以前，它无法预测一个新系统引入一个机构的影响
在用户可能需要较长等待时间来获得一个可供使用的系统，也许会给用户的信任程度带来影响和打击
最终产品往往反映用户的初始需求而不是最终需求
1.4客户需求
 
对项目而言，是否使用这一模型主要取决于是否能理解客户的需求以及在项目的进程中这些需求的变化程度；对于经常变化的项目而言，瀑布模型毫无价值，可以考虑其他的架构来进行项目管理，比如螺旋模型
 
瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：
 
各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量
由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险
早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果
按照瀑布模型的阶段划分，软件测试可以分为单元测试，集成测试，系统测试
 
 
 
二、快速原型模型
 
2.1什么是快速原型模型
 
快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集
 
快速原型模型是增量模型的另一种形式，在开发真实系统之前，迅速建造一个可以运行的软件原型 ，以便理解和澄清问题，在该原型的基础上，逐渐完成整个系统的开发工作
 
它允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速设计开发出软件系统的原型，该原型向用户展示待开发软件的全部或部分功能和性能；用户对该原型进行测试评定，给出具体改进意见以丰富细化软件需求；开发人员据此对软件进行修改完善，直至用户满意认可之后，进行软件的完整实现及测试、维护
 
 
2.2优缺点
 
优点
 
克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险
适合预先不能确切定义需求的软件系统的开发
缺点
 
所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下
使用前提是要有一个展示性的产品原型，一定程度上可能会限制开发人员的创新
2.3快速原型模型的思想产生、原理及运用方式
 
1、思想产生
 
在需求分析阶段得到完全、一致、准确、合理的需求说明十分困难
 
获得一组基本需求说明后，就快速地使其“实现”，通过原型反馈，加深对系统的理解满足用户基本要求，使用户在试用后对需求说明进行补充和精确化，从而获得合理完整、现实可行的需求说明
 
再把快速原型思想用到软件开发的其他阶段，向软件开发的全过程扩展
 
先用相对少的成本，较短的周期开发一个简单的、但可以运行的系统原型向用户演示或让用户试用，以便及早澄清并检验一些主要设计策略，在此基础上再开发实际的软件系统
 
2、原理
 
利用原型辅助软件开发
 
经过简单快速分析快速实现一个原型，用户与开发者在试用原型过程中加强通信与反馈，通过反复评价和改进原型，减少误解，弥补漏洞，最终提高软件质量
 
3、运用方式
 
由于运用原型的目的和方式不同，在使用原型时也采取不同的策略
 
抛弃策略：将原型用于开发过程的某个阶段，促使该阶段的开发结果更加完整、准确、一致、可靠，该阶段结束后，原型随之作废。探索型和实验型就是采用此策略的
附加策略：将原型用于开发的全过程，原型由最基本的核心开始，逐步增加新的功能和新的需求，反复修改反复扩充，最后发展为用户满意的最终系统，演化型快速原型就是采用此策略
采用何种形式、何种策略运用快速原型主要取决于软件项目的特点、可供支持的原型开发工具和技术等，根据实际情况的特点决定
 
 
2.4类型
 
在软件开发中，原型是软件的一个早期可运行的版本，它反映最终系统的部分重要特性
 
探索型
 
这种原型目的是要弄清对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性
 
实验型
 
这种原型用于大规模开发和实现之前，考核方案是否合适，规格说明是否可靠
 
进化型
 
这种原型的目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统
 
2.5开发步骤
 
1、快速分析
 
在分析人员与用户密切配合下，迅速确定系统的基本需求，根据原型需要体现的特征描述基本需求以满足开发原型的需要
 
2、构造原型
 
在快速分析的基础上，根据基本需求说明尽快实现一个可行的系统
 
要求具有强有力的软件工具的支持，并忽略最终系统在某些细节上的要求，主要考虑原型系统能够充分反映所要评价的特性
 
3、运行原型
 
发现问题，消除误解，开发者与用户充分协调
 
4、评价原型
 
在运行的基础上，考核评价原型的特性，分析运行效果是否满足用户的愿望，纠正过去交互中的误解与分析中的错误，增添新的要求，并满足因环境变化或用户的新想法引起的系统要求变动，提出全面的修改意见
 
5、修改
 
根据评价原型的活动结果进行修改
 
若原型未满足需求说明的要求，说明对需求说明存在不一致的理解或实现方案不够合理，根据明确的要求迅速修改原型
 
快速原型模型不带反馈环，软件产品的开发基本上是线性顺序进行的
 
快速原型的本质是"快速"。开发人员应尽可能地建造出原型系统，以加速软件开发过程，节约软件开发成本
 
原型的用途是获知用户的真正需求，一旦需求确定了，原型将被抛弃
 
 
 
三、增量模型
 
3.1什么是增量模型
 
增量模型也称渐增模型。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能
 
使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能
 
把软件产品分解成增量构件时，唯一必须遵守的约束条件是，当把新构件集成到现有构件中时，所形成的产品必须是可测试的
 
 
 
 
瀑布模型或快速原型模型目标是一次就把一个满足所有需求的产品提交给用户
 
 
增量模型把整个软件产品分解成许多个增量构件，分批地逐步向用户提交产品
 
 
3.2特点
 
把瀑布模型的顺序特征与快速原型法的迭代特征相结合
 
将软件看作一系列相互联系的增量，在开发过程的各次迭代中，每次完成其中的一个增量
 
 
 
风险更大的增量模型
 
 
确定用户需求后就着手拟定第一个构件的规格说明文档，完成后规格说明组转向第二个构件的规格说明文档，同时设计组开始涉及第一个构件
 
 
使用该方法将不同的构件并行构建，可能加快工程进度，但将冒构建无法集成到一起的风险
 
 
 
 
3.3优缺点
 
优点
 
能在较短的时间内向用户提交可完成部分工作的产品
将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展
以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统
开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整
缺点
 
由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构
在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性
如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程
3.4作用
 
1、开发初期的需求定义只是用来确定软件的基本结构，使得开发初期用户只需要对软件需求进行大概的描述；而对于需求的细节性描述，则可以延迟到增量构件开发时进行，以增量构件为单位逐个地进行需求补充。这种方式能够有效适应用户需求的变更
 
2、软件系统可以按照增量构件的功能安排开发的优先顺序，并逐个实现和交付使用。不仅有利于用户尽早用上系统，能够更好地适应新的软件环境，而且在以增量方式使用系统的过程中，还能获得对软件系统后续构件的需求经验
 
3、软件系统是逐渐扩展的，因此开发者可以通过对诸多构件的开发，逐步积累开发经验。实际上，增量式开发还有利于技术复用，前面构件中设计的算法、采用的技术策略、编写的源码等，都可以应用到后面将要创建的增量构件中去
 
4、增量式开发有利于从总体上降低软件项目的技术风险。个别的构件或许不能使用，但一般不会影响到整个系统的正常工作
 
5、实际上，在采用增量模型时，具有最高优先权的核心增量构件将会被最先交付，而随着后续构件不断被集成进系统，这个核心构件将会受到最多次数的测试。这意味着软件系统最重要的心脏部分将具有最高的可靠性，这将使得整个软件系统更具健壮性
 
 
 
四、螺旋模型
 
4.1什么是螺旋模型
 
螺旋模型是一种演化软件开发过程模型，它兼顾了快速原型的迭代特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的途径
 
螺旋模型是快速原型模型以进化的开发方式为中心，在每个项目阶段使用瀑布模型法。该模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。软件开发过程每迭代一次，软件开发又前进一个层次。用螺旋模型的软件过程如下
 
 
 
 
简化的螺旋模型
 
 
 
 
完整的数据模型
 
 
 
 
 
 
 
图中带箭头的点划线的长度代表当前累计的开发费用，螺旋线的角度值代表开发进度，螺旋线的每个周期对应于一个开发阶段
 
 
图中的四个象限代表了以下活动
 
 
制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件
风险分析：分析评估所选方案，考虑如何识别和消除风险
实施工程：实施软件开发和验证
客户评估：评价开发工作，提出修正建议，制定下一步计划
 
4.2特点
 
螺旋模型在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定
 
螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应，因此特别适用于庞大、复杂并具有高风险的系统
 
4.3优缺点
 
优点
 
对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标
减少了过多测试（浪费资金）或测试不足（产品故障多）所带来的风险
在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别
缺点
 
采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失
过多的迭代次数会增加开发成本，延迟提交时间
4.4限制条件
 
螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发
如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目
软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险
一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段

软件过程模型
要点
优点
缺点
适用范围
瀑布模型
每个阶段都有文档产出
文档驱动的有序方法
只能通过文档了解产品，交付产品可能不符合客户的要求
项目周期较短。需求是预知的，软件实现方法是成熟的；
快速原型模型
不带反馈环，线性顺序进行，本质是“快速”
确保交付的产品符合客户的要求
还没有证明无懈可击
无完整的需求说明，只有一些基本要求
增量模型
每一个增量均发布一个可操作产品
增大投资的早期回报，能在较短的时间内，提供可完成部分工作的初步产品给用户；
要求较高，要求开放的结构，可能退化为建造-修补模型
需求经常改变，开发人员数量不够
螺旋模型
强调风险分析（快速原型+瀑布模型）+风险分析
结合上述所有模型的特性，风险驱动
开发成本，只能用于大型的内部软件产品，开发者必须精通风险分析和风险排除
适用于庞大、复杂并具有高风险的系统。
喷泉模型
无间隙
各个阶段没有明显的界限，开发人员可以同步进行开发。
不利于项目的管理，要求严格管理文档，使得审核的难度加大
适用于面向对象的软件开发过程。
Rational统一过程（RUP）
迭代的，以架构为中心的，用例驱动的软件开发方法。四个阶段：初始阶段，精化阶段，构建阶段，移交阶段
针对所有关键的开发活动为每个开发成员提供了必要的准则、模版和工具指导，并确保全体成员共享相同的知识基础。简洁和清晰的过程结构，为开发过程提供较大的通用性。
缺少关于软件运行和支持等方面的内容，没有支持多项目的开发结构，这在一定程度上降低了在开发组织内大范围实现重用的可能性。
适用于大型的需求不断变化的复杂软件系统项目。
敏捷过程之极限编程（XP）
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。极限编程（XP）是敏捷过程中最富盛名的一个
高适应性，以人为本，以测试为驱动
敏捷注重人员的沟通，忽略文档的重要性，若项目人员流动大太，又给维护带来不少难度，特别项目存在新手比较多时，老员工比较累。
需要项目中存在经验较强的人，要不大项目中容易遇到瓶颈问题。
微软过程
每一个生命周期发布一个递进的版本，各生命周期持续快速地迭代循环
综合了Rational统一过程和敏捷过程的优点
对方法、工具和产品等方面不够全面
适用于商业环境下具有有限资源和有限开发时间约束的项目。

快速原型模型
 
所谓快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。
 
如下图所示（图中实线箭头表示开发过程，虚线箭头表示维护过程）。
 
 
快速原型模型的第一步是快速建立一个能反映用户主要需求的原型系统，让用户在计算机上试用它，通过实践来了解目标系统的概貌。通常，用户试用原型系统之后会提出许多修改意见，开发人员按照用户的意见快速地修改原型系统，然后再次请用户试用…一旦用户认为这个原型系统确实能做他们需要的工作，开发人员便可据此书写规格说明文档，根据这份文档开发出的软件便可以满足用户的真实需求。
 
从上图中可以看出，快速原型模型是不带反馈环的，这正是这种过程模型的主要优点：软件产品的开发基本上做到线性顺序进行的。
 
能基本上做到线性顺序开发的主要原因如下：
 
 
原型系统已经通过与用户交互而得到验证，据此产生的规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工。
 
 
开发人员通过建立原型系统已经学到了许多东西（至少知道了“系统不应该做什么，以及怎样不去做不该做的事情”），因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。
 
 
软件产品一旦交付给用户使用之后，维护便开始了。根据所需完成的维护工作种类的不同，可能需要返回到需求分析、规格说明、设计或编码等不同阶段，如上图中虚线箭头所示。
 
快速原型的本质是“快速”。开发人员应该尽可能快地建造出原型系统，以加速软件开发过程，节约软件开发成本。原型的用途是获知用户的真正需求，一旦需求确定了，原型将被抛弃。因此，原型系统的内部结构并不重要，必须迅速地构建原型然后根据用户意见迅速地修改原型。UNIX Shell 和 超文本都是广泛使用的快速原型语言，最近的趋势是，广泛地使用第四代语言（4GL）构件快速原型。
 
当快速原型的某个部分是利用软件工具由计算机自动生成的时候，可以把这部分用到最终的软件产品中。例如，用户界面通常是由快速原型的一个关键部分，当使用屏幕生成程序和报表生成程序自动生成用户界面时，实际上可以把得到的用户界面用在最终的软件产品中。

一、瀑布模型
 
     瀑布模型是应用广泛的一种软件开发模型，易于理解和掌握。 瀑布模型是将软件生命周期的各项活动规定为按照固定顺序相连的若干阶段性工作，形如瀑布流水，最终得到软件产品。因形如瀑布，故此得名。该模型比较适用于需求稳定并易于准确理解的软件项目开发。
 
      瀑布模型的优点：易于理解、开发具有阶段性、强调早期的计划及需求分析、基本可确定何时交付产品及进行测试。
 
      瀑布模型的缺点：需求调查分析只在最初进行，不能适应需求的新变化；顺序开发流程使开发经验教训不便进行前向反馈；不能反映出开发过程的反复性和迭代特性，无任何类型的风险评估，出现或隐藏的问题直到开发后期才会显露，失去了及早纠正错误或缺陷机会。
 
二、增量模型
 
      增量模型融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第1个增量往往是核心的产品，即第1个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。
 
 
     增量模型的优点：
 

       1) 由于能够在较短的时间内向用户提交一些有用的工作产品，因此能够解决用户的一些急用功能。
 

       2）由于每次只提交用户部分功能，用户有较充分的时间学习和适应新的产品。
 

       3）对系统的可维护性是一个极大的提高，因为整个系统是由一个个构件集成在一起的，当需求变更时只变更部分部件，而不必影响整个系统。
 

       增量模型的缺点：
 

       1） 由于各个
 构件是逐渐并入已有的软件
 体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。 
 

        2） 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于
  瀑布模型和
  快速原型模型，但也很容易退化为
  边做边改模型，从而使
  软件过程的控制失去整体性。
 
 
 

       3）如果增量包之间存在相交的情况且未很好处理，则必须做全盘
  系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。
 
 
 

  三、快速原型模型
 
 
 

        快速原型模型需要迅速建造一个可以运行的软件原型 ，以便理解和澄清问题，使开发人员与用户达成共识，最终在确定的客户需求基础上开发客户满意的软件产品。 快速原型模型允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速设计开发出软件系统的原型，该原型向用户展示待开发软件的全部或部分功能和性能；用户对该原型进行测试评定，给出具体改进意见以丰富细化软件需求；开发人员据此对软件进行修改完善，直至用户满意认可之后，进行软件的完整实现及测试、维护。
 
 
 

        快速原型模型的优点：克服
  瀑布模型的缺点，减少由于
  软件需求不明确带来的开发风险。
 
 
 

       
  快速原型模型的缺点：所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。