软件开发模型

一、瀑布模型

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限制条件

螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发

如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目

软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险

一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段

原文：https://blog.csdn.net/zjuwxx/article/details/97252039