论软件工程的增量及迭代.docVIP

论软件工程的增量与迭代 理解增量与迭代 定义: 增量模型: 增量模型融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第1个增量往往是核心的产品，即第1个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。采用增量模型的软件过程如下图所示： 迭代模型是RUP（Rational Unified Process，统一软件开发过程，统一软件过程)推荐的周期模型。在RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。 　　实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段（需求及其它）都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。迭代的思想如下图所示。 分析设计人员对应用领域不熟悉，难以一步到位。 中等或高风险项目 用户可参与到整个软件开发过程中 使用面向对象语言或第四代语言 软件公司自己有较好的类库和构建库 迭代模型: 　在项目开发早期需求可能有所变化。 　分析设计人员对应用领域很熟悉。 　高风险项目。 　用户可不同程度地参与整个项目的开发过程。 　使用面向对象的语言或统一建模语言 　使用CASE（Computer Aided Software Engineering，计算机辅助软件工程）工具，如Rose（Rose是非常受欢迎的物件软体开发工具。 具有高素质的项目管理者和软件研发团队。 优缺点 优点比较: 增量模型: 如果在项目既定的商业要求期限之前不可能找到足够的开发人员，在这种情况下，增量模型显得特别有用。早期的增量可以由少量的人员实现。如果核心产品的口碑不错，可以为下一个增量投入更多的人力。 增量模型可以规避技术风险。例如，一个系统需要用到一个正在开发的新硬件，而这个新硬件的交付日期不确定。因此，可以在早期的增量中避免使用这个硬件，这样可以保证部分功能按时交付给最终用户，不至于造成过分的延期。 人员分配灵活，一开始不需要投入大量人力资源。 当配备人员不能在限定的时间内完成产品时，它可以提供一种先推出核心产品的途径，可现发布部分功能给用户（对用户起镇静作用）。 增量能够有计划的管理技术风险。 迭代模型: 降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。 降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。 加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。 由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。 两种类型的另一方面区别在于迭代是基于IBM的RUP的以架构为核心，用例为驱动，角色职责划分不同，在同一时刻项目内部需求、设计、编码、测试的活动都在发生。迭代适合需求不明确、架构风险大的项目，增量适合需求比较明确，架构比较稳定，而且增量功能的实现基本不影响架构。还有一个不同就是迭代计划是基于角色的，增量计划是基于任务的。 就对风险的消除上，增量和迭代模型都能够很好的控制前期的风险并解决。但迭代模型在这方面更有优势。迭代模型更多的可以从总体方面去系统的思考问题，从最早就可以给出相对完善的框架或原型，后期的每次迭代都是针对上次迭代的逐步精化。 联系 通常情况下，在进行一款软件开发的过程中，各种开发模型并不是各自为战的，往往在各个开发阶段会用到不同的开发模型，也就是说，在一个软件产品的开发过程中，所有的开发模型都是交叉使用的，而在所有的开发模型中，用的最多的恐怕要数迭代模型和增量模型了。 对于一个软件来说，很难做到一步到位，就像吃东西一样，要一口一口的吃，想要把整个东西吞下去就容易噎着。于是，就需要分阶段进行开发的模型，各种模型交互使用。其中，迭代模型与增量模型是软件开发中经常用到的，通常情况下他们都是结合在一起使用的，相互补充、难分彼此，使项目逐步完善、逐步进化，以达到用户的要求。 增量模型适用于需求比较明确，架构比较稳定的软件开发，每次增量不影响已有的架构，在已有的架构下增加新的功能。迭代模型适用于需求不甚明确、难度比较大的软件开发。增量模型是从功能量上