论软件工程的增量与迭代.doc

论软件工程的增量与迭代1、 理解增量与迭代v 定义:增量模型: 增量模型融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第1个增量往往是核心的产品，即第1个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。采用增量模型的软件过程如下图所示：迭代模型: 迭代模型是RUP（Rational Unified Process，统一软件开发过程，统一软件过程)推荐的周期模型。在RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段（需求及其它）都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。迭代的思想如下图所示。v 通俗的理解 假设一个软件共有A、B、C、D四个功能，怎么来开发呢？ 增量模型：由少多到的进行开发，先完成一部分功能，然后再完成一部分功能，直至完成整个软件。例如先开发出功能A、B，然后开发出功能C、D。即ABCDABCD 迭代模型：先同时做出A、B、C、D四个个功能的原型，然后完成他们的基本功能，粗到细，逐步求精，接着对这些功能进行优化，最终得到功能完整的软件。即ABCD的基本功能ABCD的全部功能2、 发展历程增量模型:采用瀑布模型或采用快速原型化模型来开发软件时，是按照模型规定的开发过程，完成各开发环节的所 有任务，得到一个完整的软件，将其提交给用户。面对软件规模越来越大、软件市场竞争越来越激烈、用户要求越来越高的形势，这样开发存在很多问题。当你将一个大的完整产品提交给用户后，用户要花费很多时间来学习这个新产品，短时间内很难适应这个新产品，给工作中应用该产品带来不便；这个产品完整提交后，用户再去评价和提出修改意见就没有意义了。这样，使开发风险加大，使开发时间增长，使用户满意度降低。为了解决这个问题，必须构建新的软件开发过程模型。在这种情况下，增量模型被推出。当前,软件的趋势是朝着更大更复杂的系统发展。在产品版本的不断升级过程中,软件用户对软件可靠性和软件实用性的要求越来越高,这种需要反过来又使得软件实现越来越复杂。因此如何选择有效的软件生存周期模型,以提高软件产品的质量,减小项目失败的风险,成为软件开发项目成功的关键。在多种软件生存周期模型中,增量式开发模型以其明显的优越性为众多软件企业所青睐,是软件开发项目使用较多的模型。迭代模型: 软件需求在软件开发过程中常常发生改变，想要一次迭代就开发出最终产品是不可能的，紧迫的市场期限使得难以一下子完成一个完善的软件产品，于是便出现了迭代。早在20世纪50年代末期，软件领域中就出现了迭代模型。最早的迭代过程可能被描述为“分段模型”，其背景是H.D.Benington领导的美国空军SAGE项目。 在现阶段，很多组织都无一例外地都推荐、主张采用能显著减少风险的迭代模型。美国国防部原本提倡瀑布过程和观点，在发现那么多采用了瀑布模型的失败的项目之后，不但放弃了对它的要求，而且从1994年的报告开始，积极地鼓励采用更加现代化的迭代模型来取代瀑布模型做法。同时，中国中科院也提倡选用迭代模型。如今的迭代已经越来越多的应用在软件开发过程中。3、 选择使用条件增量模型:u 在整个项目开发过程中，需求都可能发生变化，客户接受分阶段交付u 分析设计人员对应用领域不熟悉，难以一步到位。u 中等或高风险项目u 用户可参与到整个软件开发过程中u 使用面向对象语言或第四代语言u 软件公司自己有较好的类库和构建库迭代模型:u 在项目开发早期需求可能有所变化。u 分析设计人员对应用领域很熟悉。u 高风险项目。u 用户可不同程度地参与整个项目的开发过程。u 使用面向对象的语言或统一建模语言u 使用CASE（Computer Aided Software Engineering，计算机辅助软件工程）工具，如Rose（Rose是非常受欢迎的物件软体开发工具。u 具有高素质的项目管理者和软件研发团队。4、 优缺点优点比较:增量模型:u 如果在项目既定的商业要求期限之前不可能找到足够的开发人员，在这种情况下，增量模型显得特别有用。早期的增量可以由少量的人员实现。如果核心产品的口碑不错，可以为下一个增量投入更多的人力。u 增量模型可以规避技术风险。例如，一个系统需要用到一个正在开发的新硬件，而这个新硬件的交付日期不确定。因此，可以在早期的增量中避免使用这个硬件，这样可以保证部分功能按时交付给最终用户，不至于造成过分的延期。u 人员分配灵活，一开始不需要投入大量人力资源。u 当配备人员不能在限定的时间内完成产品时，它可以提供一种先推出核心产品的途径，可现发布部分功能给用户（对用户起镇静作用）。u 增量能够有计划的管理技术风险。 迭代模型:u 降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。u 降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。u 加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。u 由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。缺点比较:增量模型:u 如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。 u 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。u 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易化为边做边改模型，从而是软件过程的控制失去整体性。迭代模型: 在项目早期开发可能有所变化 ，需有一个高素质的项目管理者和一个高技术 水平的开发团队.5、 区别与联系v 区别迭代模型和增量模型都属于并行开发的软件生命周期模型，但是这两个模型我们往往容易混淆或者不好理解。从概念上区分，增量：把软件按模块划分，依功能的重要程度定义它的开发顺序；迭代：把软件（全部模块）的基本功能实现之后再进一步完善。其次，迭代是不能并行的，迭代的并行是指迭代任务，我们看到迭代计划是比较复杂的，因此对项目经理的经验要求很高。增量模型一般是指具有底层框架和平台的项目，在该稳定的框架和平台上，来开发和增加具体的业务功能。每个增量之间相对独立，各个增量可以并行开发，增量内部是瀑布模型。两种类型的另一方面区别在于迭代是基于IBM的RUP的以架构为核心，用例为驱动，角色职责划分不同，在同一时刻项目内部需求、设计、编码、测试的活动都在发生。迭代适合需求不明确、架构风险大的项目，增量适合需求比较明确，架构比较稳定，而且增量功能的实现基本不影响架构。还有一个不同就是迭代计划是基于角色的，增量计划是基于任务的。就对风险的消除上，增量和迭代模型都能够很好的控制前期的风险并解决。但迭代模型在这方面更有优势。迭代模型更多的可以从总体方面去系统的思考问题，从最早就可以给出相对完善的框架或原型，后期的每次迭代都是针对上次迭代的逐步精化。v 联系 通常情况下，在进行一款软件开发的过程中，各种开发模型并不是各自为战的，往往在各个开发阶段会用到不同的开发模型，也就是说，在一个软件产品的开发过程中，所有的开发模型都是交叉使用的，而在所有的开发模型中，用的最多的恐怕要数迭代模型和增量模型了。 对于一个软件来说，很难做到一步到位，就像吃东西一样，要一口一口的吃，想要把整个东西吞下去就容易噎着。于是，就需要分阶段进行开发的模型，各种模型交互使用。其中，迭代模型与增量模型是软件开发中经常用到的，通常情况下他们都是结合在一起使用的，相互补充、难分彼此，使项目逐步完善、逐步进化，以达到用户的要求。 增量模型适用于需求比较明确，架构比较稳定的软件开发，每次增量不影响已有的架构，在已有的架构下增加新的功能。迭代模型适用于需求不甚明确、难度比较大的软件开发。增量模型是从功能量上