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

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

伴随我们所开发软件项目越来越复杂，传统瀑布型开发步骤不停地暴露出以下问题：
· 需求或设计中错误往往只有到了项目后期才能够被发觉比如：系统交付用户以后才发觉原先对于需求了解是错误，系统设计中问题要到测试阶段才能被发觉。
· 对于项目风险控制能力较弱项目风险在项目开发较晚时候才能够真正降低，往往是经过系统测试以后，才能确定该设计是否能够真正满足系统需求。
· 软件项目常常延期完成或开发费用超出预算项目开发进度往往会被意外发生问题所打乱，需要进行返工或其它部分额外开发周期，造成项目延期或费用超支。
· 项目管理人员专注于文档完成和审核来估量项目标进展情况所以项目经理对于项目状态估量往往是不正确，当她回复系统已完成了80%开发任务时，剩下20%开发任务实际上消耗是整个项目80%开发资源。
在传统瀑布模型中，需求和设计中问题是无法在项目开发前期被检测出来，只有当第一次系统集成时，这些设计缺点才会在测试中暴露出来，从而造成一系列返工：重新设计、编码、测试，进而造成项目标延期和开发成本上升。

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

和传统瀑布式开发模型相比较，迭代化开发含有以下特点：
· 许可变更需求
需求总是会改变，这是事实。给项目带来麻烦常常关键是需求改变和需求"蠕变"，它们会造成延期交付、工期延误、用户不满 意、开发人员受挫。经过向用户演示迭代所产生部分系统功效，我们能够尽早地搜集用户对于系统反馈，立即更正对于用户需求了解偏差，从而确保开发出来 系统真正地处理用户问题。
· 逐步集成元素
在传统项目开发中，因为要求一下子集成系统中全部模块，集成阶段往往要占到整个项目很大百分比工作量（最 高可达40%），这一阶段工作常常是不确定而且很棘手。在迭代式方法中，集成能够说是连续不停，每一次迭代全部会增量式集成部分新系统功效，要集成 元素全部比过去少得多，所以工作量和难度全部是比较低。
· 尽早降低风险
迭代化开发关键指导标准就是以架构为中心，在早期迭代中所要处理关键问题就是立即确定系统架构，经过几 次迭代来立即地设计出能够满足关键需求系统架构，这么能够快速降低整个项目标风险。等到系统架构稳定以后，项目标风险就比较低了，这个时候再去实现系统 中还未完成功效，进而完成整个项目。
· 有利于提升团体士气
开发人员经过每次迭代全部能够在短期内看到自己工作结果，从而有利于她们增强信心，愈加好地完成开发任务。而在非迭代式开发中，开发人员只有在项目靠近尾声时才能看到开发结果，在此之前相当长时间，大家还是在不确定性中探索前近。
· 生成更高质量产品
每次迭代全部会产生一个可运行系统，经过对这个可运行系统进行测试，我们在早期迭代中就能够立即发觉缺点并更正，性能上瓶颈也能够尽早发觉并处理。因为在每次迭代中总是不停地纠正错误，我们能够得到更高质量产品。
· 确保项目开发进度
每次迭代结束时全部会进行评定，来判定该次迭代有没有达成预定目标。项目经理能够很清楚地知道有哪些需求已经实现了，而且比较正确地估量项目标状态，对项目标开发进度进行必需调整，确保项目按时完成。
· 许可产品进行战术改变
迭代化开发含有更大灵活性，在迭代过程中能够随时依据业务情况或市场环境来对产品开发进行调整。比如为了同现有同类产品竞争，能够决定采取抢先竞争对手一步方法，提前公布一个功效简化产品。
· 迭代步骤本身可在进行过程中得到改善和精炼
一次迭代结束时评定不仅要从产品和进度角度来考察项目标情况，而且还要分析组织和步骤本身有什么待改善之处，方便在下次迭代中愈加好地完成任务。

迭代化方法处理关键是对于风险控制问题，从下图能够看出，传统开发步骤中系统风险要到项目开发后期（关键是测试阶段）才能够被真正降低。 而迭代化开发中风险，能够在项目开发早期经过几次迭代来立即地处理掉。在早期迭代中一旦碰到问题，如某一个迭代没有完成预定目标，我们还能够立即 调整开发进度以确保项目按时完成。通常到了项目开发后期（风险受控阶段），因为大部分高风险原因（如需求、架构、性能等）全部已经处理，这时候只需要投 入更多资源去实现剩下需求即可。这个阶段项目开发含有很强可控性，从而确保我们按时交付一个高质量软件系统。

迭代化开发不是一个高深软件工程理论，它提供了一个控制项目风险很有效机制。在日常工作我们也常常地应用到这一基础思想，如对于一个很 大型工程项目，我们常常会把它分为几期来分步实施，从而把复杂问题分解为相对轻易处理小问题，而且能够在较短周期内看到部分系统实现效果，经过尽 早暴露问题来帮助我们及早调整我们开发资源，加强项目进度可控程度，确保项目标按时完成。
3. 管理迭代化软件项目 
当我 们在实际工作中实践迭代化思想时，Rational统一开发步骤RUP(Rational Unified Process)能够给我们实践指导。RUP是一个通用软件步骤框架，它是一个以架构为中心、用例驱动迭代化软件开发步骤。RUP是从几千个软件 项目标实践经验中总结出来，对于实际项目含有很强指导意义，是软件开发行业实际上行业标准。
3.1 软件开发四个阶段 
在RUP中，我们把软件开发生命周期划分为四个阶段，每个阶段结束标志就是一个关键里程碑（以下图所表示）。

这四个阶段关键是为了达成以下阶段性目标里程碑：
· 先启(Inception)：确定项目开发目标和范围
· 精化(Elaboration)：确定系统架构和明确需求
· 构建(Construction)：实现剩下系统功效
· 产品化(Transition)：完成软件产品化工作，将系统移交给用户
每个目标里程碑全部是一个商业上决议点，如先启阶段结束以后，我们就要决定这个项目是否可行、是否要继续做这个项目。每一个阶段全部是由里程碑来决定，判定一个阶段是否结束标志就是看项目目前状态是否满足里碑中所要求条件。
从这种阶段划分模式中能够看出，项目标关键风险集中在前两个阶段。在精化阶段中经过几次迭代后，我们要为系统建立一个稳定架构，在此以后再实现更 多系统需求时，不再需要对该架构进行修改。同时，在精化阶段中，我们经过迭代来不停地搜集用户需求反馈，便得系统需求逐步地明确和完整。
3.2 相关开发资源分配 
基于 RUP风险驱动迭代化开发模式，我们只需要在项目标先启阶段投入少许资源，对项目标开发前景和商业可行性进行部分探索性研究。在精化阶段再投入多一 些研发力量来实现部分和架构相关关键需求，逐步地把系统架构搭建起来。等到这两个阶段结束以后，项目标部分关键风险和问题也得到了处理，这时候再投入 整个团体进行全方面系统开发。等到产品化阶段，关键开发任务已经全部完成，项目不再需要维持一个大规模开发团体，开发资源也能够随之而降低。在项目开 发周期中，开发资源分配能够以下图所表示。

这么安排能够最充足有效地利用企业开发资源，缓解软件企业对于人力资源不停增加需求，从而降低成本。另外首先，因为前两个阶段（先启和精化） 风险较高，我们只是投入部分资源，一旦发生返工或是项目目标改变，我们也能够将资源浪费降到最低点。在传统软件开发步骤中，对于开发资源分配基 本上是贯穿整个项目周期而不变，资源往往没有得到充足有效地利用。
基于这种资源分配模式，一个经典项目在项目进度和所完成工作量之间关系可能以下表中数据所表示。

先启
精化
构建
产品化
工作量
~5%
20%
65%
10%
进度
10%
30%
50%
10%
3.3 迭代策略 
相关迭代计划安排，通常有以下四种经典策略模式：
· 增量式(Incremental)
这种模式特点是项目架构风险较小（往往是开发部分反复性项目），所以精化阶段只需要一个迭代。但项目标开发工作量较大，构建阶段需要有数次迭代来实现，每次迭代全部在上一次迭代基础上增加实现一部分系统功效，经过迭代进行而逐步实现整个系统功效。
· 演进式(Evolutionary)
当项目架构风险较大时（从未开发过类似项目），需要在精化阶段经过数次迭代来建立系统架构，架构是经过数次迭代探索，逐步演化而来。当架构建立时，往往系统功效也已经基础实现，所以构建阶段只需要一次迭代。
· 增量提交(Incremental Delivery)
这种模式特点产品化阶段迭代较多，比较常见例子是项目标难度并不 大，但业务需求在不停地发生改变，所以需要经过迭代来不停地布署完成系统；但同时又要不停地搜集用户反馈来完善系统需求，并经过后续迭代来补充实现 这些需求。应用这种策略时要求系统架构很稳定，能够适应满足后续需求改变要求。
· 单次迭代(Grand Design)
传统瀑布模型能够看作是迭代化开发一个特例，整个开发步骤只有一次迭代。但这种模式有一个固有弱点，因为它对风险控制能力较差，往往会在产品化阶段产生部分额外迭代，造成项目标延误。
这多个迭代策略只是部分经典模式代表，实际应用中应依据实际情况灵活应用，最常见迭代计划往往是这多个模式组合。
3.4 制订项目开发计划 
在迭代 化开发模式中，项目开发计划也是伴随项目标进展而不停细化、调整并完善。传统项目开发计划是在项目早期制订，项目经理总是试图在项目标一开始就制 定一个很具体完善开发计划。和之相反，迭代开发模式认为在项目早期只需要制订一个比较粗略开发计划，因为伴随项目标进展，项目标状态在不停地发生变 化，项目经理需要随时依据迭代结果来对项目计划进行调整，并制订下一次迭代具体计划。
在RUP中，我们把项目开发计划分为以下三部分：
· 项目计划
确定整个项目标开发目标和进度安排，包含每一个阶段起止时间段。
· 阶段计划
目前阶段中包含有多个迭代，每一次迭代要达成目标和进度安排。
· 迭代计划
针对目前迭代具体开发计划，包含开发活动和相关资源分配。
项目开发计划也是完全表现迭代化思想，每次迭代中项目经理全部会依据项目情况来不停地调整和细化项目开发计划。迭代计划是在对上一次迭代结果进行评 估基础上制订，假如上一次迭代达成了预定目标，那么目前迭代只需要处理剩下问题；假如上一次迭代中留有部分问题还没有处理，则目前迭代还需要继续 去处理这些问题。所以必需注意，迭代是不能重合，即你还没有完成目前迭代时，你决不能进入下一迭代，因为下一次迭代计划是依据目前迭代结果而制订 。