第7 章增量模型
7.1 概述
7.2 渐增模型
7.3 快速原型模型
7.4 快速原型的开发技术和开发环境 7.5 增量模型的评价
返回主目录
第7章增量模型
7.1 概述
7.1.1瀑布模型的局限性
传统的瀑布模型给软件产业带来了巨大的进步，部分地缓解了软件危机，但这种模型本质上是一种线性顺序模型，存在着比较明显的缺点，各阶段之间存在着严格的顺序性和依赖性，特别是强调预先定义需求的重要性，在着手进行具体的开发工作之前，必须通过需求分析预先定义并“冻结”软件需求，然后再一步一步的实现这些需求。但是实际项目很少是遵循着这种线性顺序进行的。虽然瀑布模型也允许迭代，但这种改变往往对项目开发带来混乱。
1. 需求是可变的
某些应用软件的需求与外部环境、公司经营策略或经营内容等密切相关，因此需求是随时变化的，在不同时间用户的需求可能有较大的不同，采用预先定义整体不变的需求的策略，在一年或数年之前预先指定对需求随时间变化的软件的需求，显然是不切实际的。按照这样预先指定的需求开发软件，当软件开发出来的时候就已经过时了，不符合那时的用户需要了。然而按照瀑布模型开发，在开发后期修改需求要付出很高的代价，甚至根本不可能修改。
2. 需求是模糊的
对于某些类型的软件系统，如操作系统、编译系统等系统软件，人们对它们比较熟悉，有长期使用它们的经验，其需求经过仔细的分析之后可以预先指定。但是，对于大多数更常使用的应用系统，例如管理信息系统，其需求往往很难预先准确的指定，也就是说，预先定义需求的策略所做出的假设，只对某些软件成立，对多数软件并不成立。许多用户对他们的需求最初只有模糊的概念，想要求一个对需求只有初步设想的人准确无误的说出全部需求，显然是不切实际的。人们为了充实和细化他们的初步设想，通常需要经过在某个能运行的系统上进行实践的过程。
3. 用户和开发者难于沟通
大型软件的开发需要系统分析员、软件工程师、程序员、用户和领域专家等各类人员的协同配合。因此良好的通信和相互理解对于保证工程成功是至关重要的。大多数用户和领域专家不熟悉计算机和软件技术，软件开发人员也往往不熟悉用户的专业领域，特别在涉及各种不同领域的知识时，情况更是如此。因此，开发人员和用户之间很难做到完全沟通和相互理解，在需求分析阶段做出的用户需求常常是不完整、不准确的。因此，即使用户签字同意了的需求说明书，也并不能保证根据这份说明书开发出来的软件系统就能真正满足用户的需要。
7.1.2增量模型的基本思想
增量模型和瀑布模型之间的本质区别是：瀑布模型属于整体开发模型，它规定在开始下一个阶段的工作之前，必须完成前一阶段的所有细节。而增量模型属于非整体开发模型，它推迟某些阶段或所有阶段中的细节，从而较早地产生工作软件。 增量模型是在项目的开发过程中以一系列的增量方式开发系统。增量方式包括增量开发和增量提交。增量开发是指在项目开发周期内，以一定的时间间隔开发部分工作软件；增量提交是指在项目开发周期内，以一定的时间间隔增量方式向用户提交工作软件及相应文档。增量开发和增量提交可以同时使用，也可单独使用。
7.1.3增量模型的分类
有多种增量模型，根据增量的方式和形式的不同，分为渐增模型和原型模型。
1. 渐增模型
这种模型是瀑布模型的变种，有两类渐增模型：
(1) 增量构造模型：是在瀑布模型的基础上，对一些阶段进行整体开发，对另一些阶段进行增量开发。也就是说在前面的开发阶段按瀑布模型进行整体开发，后面的开发阶段按增量方式开发。
(2) 演化提交模型：是在瀑布模型的基础上，所有阶段都进行增量开发，即不仅是增量开发，也是增量提交。
2. 原型模型
这种开发模型又称快速原型模型，它是增量模型的另一种形式。它是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。根据原型的不同作用，有以下三类原型模型：
(1) 探索型原型：其原型模型是把原型用于开发的需求分析阶段，目的是要弄清用户的需求，确定所期望的特性，并探索各种方案的可行性。它主要针对开发目标模糊，用户与开发者对项目都缺乏经验的情况，通过对原型的开发来明确用户的需求。
(2) 实验型原型：主要用于设计阶段，考核实现方案是否合适，能否实现。
对于一个大型系统，若对设计方案心中没有把握时，可通过这种原型来证实设计方案的正确性。
(3) 演化型原型：主要用于及早向用户提交一个原型系统，该原型系统包含系统的框架，或包含系统的主要功能，在得到用户的认可后，将原型系统不断扩充演变为最终的软件系统。它将原型的思想扩展到软件开发的全过程。
7.2 渐增模型
7.2.1 增量构造模型
增量构造模型如图7.1所示。在该模型中，需求分析阶段和设计阶段都是按瀑布模型的整体方式开发，但是编码阶段和测试阶段是按增量方式开发。在这种模型的开发中，用户可以及早看到部分软件功能，及早发现问题，以便在开发其他软件功能时及时解决问题。
图7.1 增量构造模型需求分析
设计
编码1测试1编码2测试2编码3
测试3
7.2.2演化提交模型
演化提交模型的表示如图7.2所示。
在该模型中，项目开发的各个阶段都是增量方式。先对某部分功能进行需求分析，然后顺序进行设计、编码和测试，把该功能的软件交付给用户，再对另一部分功能进行开发，提交用户直至所有功能全部增量开发完毕为止。开发的顺序按图7.2中的编号进行。该模型是增量开发的极端形式，它不仅是增量开发也是增量提交，用户将最早收到部分工作软件，能及早发现问题，使修改扩充更容易了。
图7.2
演化提交模型1
2
34
5
6
789
10
11
12
需求分析设计编码测试
7.3 快速原型模型
7.3.1基本思想
1. 原型
原型是指模拟某种产品的原始模型，在其他产业中经常使用模型。例如，在建造一座楼房时，先按一定的比例建造一个缩小的楼房模型，通过楼房模型的外观、形状和颜色的直接理解和认识，加强了对要建造的真正楼房的理解和认识。模型直观性很强，很容易发现那些不满意的设计，也很容易进行修改，经过用户和建设者反复讨论修改，最终可得到用户满意的模型，然后按照这个模型正式建造，这座楼房自然能满足用户要求。
而软件开发中的原型是软件的一个早期可运行的版本，它反映了最终系统的重要特性。
2. 快速原型思想的产生
在80年代就出现了快速原型的思想，它是在研究需求分析阶段的方法和技术中产生的。由于种种原因，在需求分析阶段得到完全、一致、准确和合理的需求说明是很困难的。因此在开发过程的早期，在获得一组基本需求说明后，就快速地使其“实现”，通过原型反馈，加深对系统的理解，并满足用户基本要求，使用户在试用过程中受到启发，对需求说明进行补充和精确化，还增进了开发者和用户对系统需求的理解。使比较含糊的软件需求和功能明确化，还帮助开发者和用户发现和消除不协调的系统需求，逐步确定各种需求，从而获得合理、协调一致、无歧义的、完整的和现实可行的需求说明。
以后，又把快速原型思想用到软件开发的其他阶段，并向软件开发的全过程扩展，即先用相对少的成本，较短的周期开发一个简单的、但可以运行的系统原型向用户演示或让用户试用，以便及早澄清并检验一些主要设计策略，在此基础上再开发实际的软件系统。
3. 快速原型的原理
快速原型是利用原型辅助软件开发的一种新思想。经过简单快速分析，快速实现一个原型，用户与开发者在试用原型过程中加强通讯与反馈，通过反复评价和改进原型，减少误解，弥补遗漏，适应变化，最终提高软件质量。
4. 原型运用方式
由于运用原型的目的和方式不同，在使用原型时也采取不同的策略，有抛弃策略和附加策略。
抛弃策略是将原型用于开发过程的某一阶段，促使该阶段的开发结果更加完整、准确、一致和可靠，该阶段结束后，原型随之作废。探索型和实验型快速原型就是采用此策略的。
附加策略是将原型用于开发的全过程，原型由最基本的核心开始，逐步增加新的功能和新的需求，反复修改反复扩充，最后成为用户满意的最终系统。演化型快速原型就采用此策略。
7.3.2快速原型模型表示
快速原型模型的表示如图7.3所示。图7.3（a）说明了原型本身的表示，图7.3（b）说明了原型的使用过程，图7.3（c）说明了快速原型模型的开发过程。
在图7.3（c）中，实线箭头连接的表示探索型快速原型模型的开发过程，双线箭头连接的表示实验型快速原型模型的开发过程，虚线箭头连接的表示演化型快速原型模型的开发过程。
对于探索型，用原型过程来替需求分析，把原型作为需求说明的补充形式，运用原型尽可能使需求说明完整、一致、准确和无二义性，但在整体上仍采用瀑布模型。
图7.3快速原型模型
(a) 原型；(b) 原型的使用；(c) 开发过程需求说明
快速分析
(b )
执行顺序
构造
评价原型修改
快速分析
(a )
构造原型
原型运行原型评价原型
修改意见修改类型停止修改修
改
原
型修改说明需求说明需求分析
设计设计说明编码源程序测试软件产品
维护
(c )运行
对于实验型，用原型过程来代替设计阶段，即在设计阶段引入原型，快速分析实现方案，快速构造原型，通过运行，考察设计方案的可行性与合理性，原型成为设计的总体框架或设计结果的一部分。
对于演化型，用原型过程来代替全部开发阶段。这是典型的演化提交模型的形式，它是在强有力的软件工具和环境支持下，通过原型过程的反复循环，直接得到软件系统。不强调开发的严格阶段性和高质量的阶段性文档，不追求理想的开发模式。