迭代软件开发作业流程.docVIP

1.传统开发步骤问题?

传统软件开发步骤是一个文档驱动步骤，它将整个软件开发过程划分为次序相接多个阶段，每个阶段全部必需完成全部要求任务（文档）后才能够进入下一个阶段。如必需完成全部系统需求规格说明书以后才能够进入概要设计阶段，编码必需在系统设计完成以后才能够进行。这就意味着只有当全部系统模块全部开发完成之后，我们才进行系统集成，对于一个由上百个模块组复杂系统来说，这是一个很艰巨而漫长工作。

伴随我们所开发软件项目越来越复杂，传统瀑布型开发步骤不停地暴露出以下问题：

需求或设计中错误往往只有到了项目后期才能够被发觉比如：系统交付用户以后才发觉原先对于需求了解是错误，系统设计中问题要到测试阶段才能被发觉。

对于项目风险控制能力较弱项目风险在项目开发较晚时候才能够真正降低，往往是经过系统测试以后，才能确定该设计是否能够真正满足系统需求。

软件项目常常延期完成或开发费用超出预算项目开发进度往往会被意外发生问题所打乱，需要进行返工或其它部分额外开发周期，造成项目延期或费用超支。

项目管理人员专注于文档完成和审核来估量项目标进展情况所以项目经理对于项目状态估量往往是不正确，当她回复系统已完成了80%开发任务时，剩下20%开发任务实际上消耗是整个项目80%开发资源。

在传统瀑布模型中，需求和设计中问题是无法在项目开发前期被检测出来，只有当第一次系统集成时，这些设计缺点才会在测试中暴露出来，从而造成一系列返工：重新设计、编码、测试，进而造成项目标延期和开发成本上升。

2.采取迭代化开发控制项目风险?

为了处理传统软件开发步骤中问题，我们提议采取迭代化开发方法来替换瀑布模型。在瀑布模型中，我们要完成是整个软件系统开发这个大目标。在迭代化方法中，我们将整个项目标开发目标划分成为部分更易于完成和达成阶段性小目标，这些小目标全部有一个定义明确阶段性评定标准。迭代就是为了完成一定阶段性目标而所从事一系列开发活动，在每个迭代开始前全部要依据项目目前状态和所要达成阶段性目标制订迭代计划，整个迭代过程包含了需求、设计、实施（编码）、布署、测试等多种类型开发活动，迭代完成以后需要对迭代完成结果进行评定，并以此为依据来制订下一次迭代目标。

和传统瀑布式开发模型相比较，迭代化开发含有以下特点：

许可变更需求

需求总是会改变，这是事实。给项目带来麻烦常常关键是需求改变和需求蠕变，它们会造成延期交付、工期延误、用户不满意、开发人员受挫。经过向用户演示迭代所产生部分系统功效，我们能够尽早地搜集用户对于系统反馈，立即更正对于用户需求了解偏差，从而确保开发出来系统真正地处理用户问题。

逐步集成元素

在传统项目开发中，因为要求一下子集成系统中全部模块，集成阶段往往要占到整个项目很大百分比工作量（最高可达40%），这一阶段工作常常是不确定而且很棘手。在迭代式方法中，集成能够说是连续不停，每一次迭代全部会增量式集成部分新系统功效，要集成元素全部比过去少得多，所以工作量和难度全部是比较低。

尽早降低风险

迭代化开发关键指导标准就是以架构为中心，在早期迭代中所要处理关键问题就是立即确定系统架构，经过几次迭代来立即地设计出能够满足关键需求系统架构，这么能够快速降低整个项目标风险。等到系统架构稳定以后，项目标风险就比较低了，这个时候再去实现系统中还未完成功效，进而完成整个项目。

有利于提升团体士气

开发人员经过每次迭代全部能够在短期内看到自己工作结果，从而有利于她们增强信心，愈加好地完成开发任务。而在非迭代式开发中，开发人员只有在项目靠近尾声时才能看到开发结果，在此之前相当长时间，大家还是在不确定性中探索前近。

生成更高质量产品

每次迭代全部会产生一个可运行系统，经过对这个可运行系统进行测试，我们在早期迭代中就能够立即发觉缺点并更正，性能上瓶颈也能够尽早发觉并处理。因为在每次迭代中总是不停地纠正错误，我们能够得到更高质量产品。

确保项目开发进度

每次迭代结束时全部会进行评定，来判定该次迭代有没有达成预定目标。项目经理能够很清楚地知道有哪些需求已经实现了，而且比较正确地估量项目标状态，对项目标开发进度进行必需调整，确保项目按时完成。

许可产品进行战术改变

迭代化开发含有更大灵活性，在迭代过程中能够随时依据业务情况或市场环境来对产品开发进行调整。比如为了同现有同类产品竞争，能够决定采取抢先竞争对手一步方法，提前公布一个功效简化产品。

迭代步骤本身可在进行过程中得到改善和精炼

一次迭代结束时评定不仅要从产品和进度角度来考察项目标情况，而且还要分析组织和步骤本身有什么待改善之处，方便在下次迭代中愈加好地完成任务。

迭代化方法处理关键是对于风险控制问题，从下图能够看出，传统开发步骤中系统风险要到项目开发后期（关键是测试阶段）才能够被真正降低。而迭代