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

论软件工程中的增量与迭代 之前的论文中我有写道，随着软件技术的开发，单纯的瀑布模型已经难以应对不断变化不断升级的客户需求，并且软件危机也逐渐暴露出来。为了能够在变幻莫测的现实环境中以可预期方式交付结果，“迭代”方法应运而生。“不确定性”将持续存在，我们需要采用一种与之抗衡的技术，这种技术就是迭代和增量开发，借助这种技术赋予的力量，我们能够克服不确定性，或至少能系统降低不确定性，使其处于可控范围，以达到预期的目标。我们将分别看一下迭代开发和增量开发并且比较两者的异同。 迭代开发 当客户并不明白自身需要的时候，或者当客户的需求不断变化的时候，原始的瀑布模型就需要推翻重新开始软件的设计。这时，我们不指望我们所构建的软件正是用户所想要的，但我们可以先构建后修改，通过多次修改找到真正适合用户的软件。比如开发一个软件的周期是一年，那么我们可以用两个月的时间向用户提交一个预览版本，可能这个版本还没有友好的界面，也没有强大的功能甚至存在bug，用户会提出意见，之后把前两个月所作的需求分析、框架设计、代码、测试等等的基础上，进一步改进，又拿出一个更完善的产品来。这就是一个迭代开发的过程。 文学上讲，迭代是一个反复执行的动作。为了解决传统软件开发流程中的问题，人们逐渐设计了迭代化的开发方法来取代瀑布模型。在瀑布模型中，我们要完成的是整个软件系统开发这个大目标。在迭代的方法中，我们将整个项目的开发目标划分成为一些更易于完成和达到的阶段性小目标，这些小目标都有一个定义明确的阶段性评估标准。迭代就是为了完成一定的阶段 性目标而所从事的一系列开发活动，在每个迭代开始前都要根据项目当前的状态和所要达到的阶段性目标制定迭代计划，整个迭代过程包含了需求、设计、实施（编 码）、部署、测试等各种类型的开发活动，迭代完成之后需要对迭代完成的结果进行评估，并以此为依据来制定下一次迭代的目标。 与传统的瀑布式开发模型相比较，迭代化开发具有以下特点： 允许变更需求 逐步集成元素 尽早降低风险 有助于提高团队的士气 生成更高质量的产品 保证项目开发进度 容许产品进行战术改变 迭代流程自身可在进行过程中得到改进和精炼 同时迭代化开发过程也存在一些缺点，在项目早期开发可能有所变化 ，需有一个高素质的项目管理者和一个高技术水平的开发团队。 增量开发 简而言之，增量开发就是构造一系列的可执行的中间版本。增量模型强调每一个增量均发布一个可操作产品，在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样使软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。 增量模型一般具有底层框架和平台的项目，在该稳定的框架和平台上，来开发和增加具体的业务功能。每个增量之间相对独立，各个增量可以并行开发，增量内部是瀑布模型。把软件按模块划分，依功能的重要程度定义它的开发顺序，这样就保证了用户可以比较快的看到一款开执行的版本；而且，在此基础上，用户也能够更好地提出需求，完善产品的功能。另一方面，迭代增量模型是任务或者说是功能模块驱动，而且，由于规划了开发顺序，核心的框架已经存在，开发人员可以分模块进行，然后再集成、测试，如此大大的提高了开发效率，也提高了产品的稳定性和实用性。 采用增量模型的软件过程如下图所示： 这一模型的优点是 1) 由于能够在较短的时间内向用户提交一些有用的工作产品，因此能够解决用户的一些急用功能。 2）由于每次只提交用户部分功能，用户有较充分的时间学习和适应新的产品。 3）对系统的可维护性是一个极大的提高，因为整个系统是由一个个构件集成在一起的，当需求变更时只变更部分部件，而不必影响整个系统。 但是我们仍然不能忽视缺点的存在。增量模型存在以下缺陷： 1） 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。 2） 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。 3）如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。 迭代与增量开发模型的共性与区别 上面只是在概念上对迭代和增量的介绍，下面也实例来说明他们有什么相似之处与不同之处。 假设一个软件共有A、B、C、D、四个功能，我们要怎么来开发呢？ 我们可以四个功能同时做，由粗到细，逐步求精，最终完成整个软件。整个过程可以是先做出A、B、C、D、四个功能的原型，然后完成他们的基本功能，接着对这些功能进行优化和完善，最终得到