六大软件开发模型详解

软件测试工作与软件开发模型息息相关，在不同的软件开发模型中，测试的任务和作用也不相同，因此测试人员要充分了解软件开发模型，以便找准自己在其中的定位与任务。软件开发模型规定了软件开发应遵循的步骤，是软件开发的导航图，它能够清晰、直观地表达软件开发的全过程，以及每个阶段要进行的活动和要完成的任务。开发人员在选择开发模型时，要根据软件的特点、开发人员的参与方式选择稳定可靠的开发模型自有软件开发以来，软件开发模型也从最初的“边做边改”发展出了多个模型，下面以软件开发模型发展历史为顺序，介绍几个典型的开发模型。

1. 瀑布模型

瀑布模型是W.W.罗伊斯(W.W.Royce)于1970年提出的软件开发模型，由模型名称可知该模型遵循从上至下一次性完成整个软件产品的开发方式瀑布模型将软件开发过程分为6个阶段:计划→需求分析→软件设计→编码→测试→运行维护，其开发过程如图1-1所示。

图1-1 瀑布模型

在瀑布模型中，软件开发的各项活动严格按照这条线进行，只有当一个阶段任务完成之后才能开始下一个阶段。软件开发的每一个阶段都要有结果产出，结果经过审核验证之后作为下一个阶段的输入，下个阶段才可以顺利进行。如果结果审核验证不通过，则需要返回修改。

瀑布模型为整个项目划分了清晰的检查点，当一个阶段完成之后，只需要把全部精力放置在后面的开发上即可，它有利于大型软件开发人员的组织管理及工具的使用与研究，可以提高开发的效率。

但是瀑布模型是严格按照线性方式进行的，无法适应用户需求变更，用户只能等到最后才能看到开发成果，增加了开发风险。如果开发人员与客户对需求理解有偏差，到最后开发完成后，最终成果与客户需求可能会差之千里。使用瀑布模型开发软件时，如果早期犯的错误在项目完成后才发现，此时再修改原来的错误需要付出巨大的代价。瀑布模型要求每一个阶段必须有结果产出，这就势必增加了文档的数量，使软件开发的工作量变大。

除此之外，对于现代软件来说，软件开发各阶段之间的关系大部分不会是线性的，很难使用瀑布模型开发软件，因此瀑布模型不再适合现代软件开发，已经被逐渐废弃。

2、 快速原型模型

快速原型模型与瀑布模型正好相反，它在最初确定用户需求时快速构造岀一个可以运行的软件原型，这个软件原型向用户展示待开发软件的全部或部分功能和性能，客户对该原型进行审核评价，然后给出更具体的需求意见，这样逐步丰富细化需求，最后开发人员与客户达成最终共识，确定客户的真正需求。确定客户的真正需求之后，开始真正的软件开发。

快速原型模型类似于建造房子，确定客户对房子的需求之后快速地搭建一个房子模型，由客户对房子模型进行评价，房子的样式、功能、布局等是否满足需求，哪里需要改进等，最后确定了客户对房子的要求，就开始真正地建造房子。该模型的开发过程如图1-2所示。

 

图1-2 快速原型模型

与瀑布模型相比，快速原型模型克服了需求不明确带来的风险，适用于不能预先确定需求的软件项目。但快速原型模型关键在于快速构建软件原型，准确地设计出软件原型存在定的难度。此外，这种开发模型也不利于开发人员对产品进行扩展。

3、 迭代模型与增量模型

在关于软件过程的书籍和文章里，增量、迭代可以说是如雷贯耳，但也带来了概念上的混淆，不知道他们有什么共同之处和区别，甚至以为是同一个概念。下面也实例来说明他们有什么相似之处与不同之处。

假设一个软件共有A、B、C、D、E五个功能，怎么来开发呢？

①我们可以五个功能同时做，由粗到细，逐步求精，最终完成整个软件。整个过程可以是先做出A、B、C、D、E五个功能的原型，然后完成他们的基本功能，接着对这些功能进行优化，最终得到功能完整的软件。这样的开发过程就是迭代模型。该模型的开发过程如图1-3所示。

 图1-3 迭代模型

②我们也可以由少多到的进行开发，先完成一部分功能，然后再完成一部分功能，直至完成整个软件。例如先开发出功能A、B，然后开发出功能C、D，最后开发出功能E。这样的开发过程就是增量模型。该模型的开发过程如图1-4所示。

  图1-4 增量模型

对于一个软件来说，很难做到一步到位，就像吃东西一样，要一口一口的吃，想要把整个东西吞下去就容易噎着。于是，就出现了分阶段进行开发的模型，逐步达到目标，迭代模型、增量模型就是这样的。
他们的共同点是，通过若干个阶段的开发，完成整个软件，每阶段完成之后，都有一个新版本发布。这就有一个好处，相对于整个漫长的开发周期来说，每阶段都会见到亮光，有利于鼓舞团队的士气，降低项目的风险。
至于不同点，主要是阶段的划分上不太一样。增量模型是从功能量上来划分的，每阶段完成一定的功能。迭代模型是从深度或细化的程度来划分的，每阶段功能得到完善、增强。
增量模型适用于需求比较明确，架构比较稳定的软件开发，每次增量不影响已有的架构，在已有的架构下增加新的功能。迭代模型适用于需求不甚明确、难度比较大的软件开发。
在实际应用中，增量、迭代经常一起使用，如迭代时加入新的功能进行开发，这也是他们经常一起出现的原因。

4、 螺旋模型

螺旋模型由巴利·玻姆(Barry Boehm)于1988年提岀，该模型融合了瀑布模型、快速原型模型，它最大的特点是引入了其他模型所忽略的风险分析，如果项目不能排除重大风险，就停止项目从而减小损失。这种模型比较适合开发复杂的大型软件。

螺旋模型将整个项目开发过程划分为几个不同的阶段，每个阶段按部就班地执行，这种划分方式采用了瀑布模型。每个阶段在开始之前都要进行风险评估，如果能消除重大风险则可以开始该阶段任务。在每个阶段，首先构建软件原型，根据快速原型模型完成这个迭代过程，产出最终完善的产品，然后进入下一个阶段，同样下一个阶段开始之前也要进行风险评估，这样循环往复直到完成所有阶段的任务。螺旋模型的若干个阶段是沿着螺线方式进行的，如图1-5所示。

 

图1-5 螺旋模型

图1-5有4个象限:制订计划、风险分析、实施工程、客户评估，各象限含义如下。

(1)制订计划:确定软件目标，制订实施方案，并且列出项目开发的限制条件。

(2)风险分析:评价所制订的实施方案，识别风险并消除风险。

(3)实施工程:开发产品并进行验证

(4)客户评估:客户对产品进行审核评估，提出修正建议，制订下一步计划。

在螺旋模型中，每一个选代都需要经过这4个步骤，直到最后得到完善的产品，可以进行提交。

螺旋模型强调了风险分析，这意味着对可选方案和限制条件都进行了评估，更有助于将软件质量作为特殊目标融入产品开发之中。它以小分段构建大型软件，使成本计算变得简单容易，而且客户始终参与每个阶段的开发，保证了项目不偏离正确方向，也保证了项目的可控制性。

5、敏捷模型

敏捷模型是20世纪90年代兴起的一种软件开发模型。在现代社会,技术发展非常快软件开发也是在快节奏的环境中进行的。在业务快速变换的环境下,往往无法在软件开发之前收集到完整而详尽的软件需求。没有完整的软件需求,传统的软件开发模型就难以展开工作。

为了解决这个问题,人们提出了敏捷开发模型。敏捷模型以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷模型中,软件项目在构建初期被拆分为多个相互联系而又独立运行的子项目,然后迭代完成各个子项目,开发过程中,各个子项目都要经过开发测试。当客户有需求变更时,敏捷模型能够迅速地对某个子项目做出修改以满足客户的需求。在这个过程中,软件一直处于可使用状态。

除了响应需求,敏捷模型还有一个重要的概念——迭代,就是不断对产品进行细微、渐进式的改进,每次改进一小部分,如果可行再逐步扩大改进范围。在敏捷模型中,软件开发不再是线性的,开发的同时也会进行测试工作,甚至可以提前写好测试代码,因此在敏捷模有“开发未动,测试先行”的说法。

另外,相比于传统的软件开发模型,敏捷模型更注重“人”在软件开发中的作用,项目的各部门应该紧密合作、快速有效地沟通(如面对面沟通),提出需求的客户可以全程参与到开发过程,以适应软件频繁的需求变更。为此,敏捷模型描述了一套软件开发的价值和原则,具体如下所示。

(1)个体和交互重于过程和工具。

(2)可用软件重于完备文档。

(3)客户协作重于合同谈判。

(4)响应变化重于遵循计划。

对于敏捷模型来说,并不是工具、文档等不重要,而是更注重人与人之间的交流沟通。

敏捷模型可以及时响应客户需求变更,不断适应新的趋势,但是在开发灵活的同时也带来了一定程度的混乱。例如,缺乏文档资料;软件之前版本的可重现性、可回溯性较低;对于较大的项目,人员越多,面对面的有效沟通越困难。因此敏捷模型比较适用于小型项目的开发,而不太适用于大型项目。