软件开发面临的流程问题.doc

软件开发，面临的流程问题 ——复杂的问题，需要FI 积月累的积攒 传统开发流程的问题 传统的软件开发流程是一个文档驱动的流程，它 将整个软件开发过程划分为顺序相接的几个阶段，每 个阶段都必需完成全部规定的任务（文档）后才能够进 入下一个阶段。如必须完成全部的系统需求规格说明 书之后才能够进入概要设计阶段，编码必需在系统设 计完成之后才能够进行。这就意味着只有当所有的系 统模块全部开发完成之后，我们才进行系统集成，对 于一个由上百个模块组的复杂系统来说，这是一个非 常艰巨而漫长的工作。 随着我们所开发的软件项目越来越复杂，传统的 瀑布型开发流程不断地暴露出以下问题： 需求或设计中的错误往往只有到了项目后期才能 够被发现例如：系统交付客户之后才发现原先对于需 求的理解是错误的，系统设计中的问题要到测试阶段 才能被发现。 对于项目风险的控制能力较弱项目风险在项目开 发较晚的时候才能够真正降低，往往是经过系统测试 之示，才能确定该设计是否能够真正满足系统需求。 软件项目常常延期完成或开发费用超出预算项目 开发进度往往会被意外发生的问题所打乱，需要进行 返工或其他一些额外的开发周期，造成项目延期或费 用超支。 项M管理人员专注于文档的完成和审核来估计项 目的进展情况所以项目经理对于项目状态的估计往往 是不准确的，当他回答系统已完成了 80%的开发任务 时，剩下20%的开发任务实际上消耗的是整个项目80% 的开发资源。 在传统的瀑布模型中，需求和设计中的问题是无 法在项目开发的前期被检测出来的，只有当第一次系 统集成时，这些设计缺陷才会在测试中暴露出来，从 而导致一系列的返工：重新设计、编码、测试，进而 导致项目的延期和开发成本的上升。 随着我们所开发的软件项目越来越复杂，传统的 瀑布型开发流程不断地暴露出以下问题: 需求或设计中的错误往往只有到了项目后期才能 够被发现例如：系统交付客户之后才发现原先对于需 求的理解是错误的，系统设计中的问题要到测试阶段 才能被发现。 对于项1=1风险的控制能力较弱项U风险在项U开 发较晚的时候才能够真正降低，往往是经过系统测试 之后，才能确定该设计是否能够真正满足系统需求。 软件项U常常延期完成或开发费用超出预算项U 开发进度往往会被意外发生的问题所打乱，需要进行 返工或其他一些额外的开发周期，造成项目延期或费 用超支。 项目管理人员专注于文档的完成和审核来估计项 0的进展情况所以项目经理对于项目状态的估计往往 是不准确的，当他回答系统已完成了 80%的开发任务 时，剩下20%的开发任务实际上消耗的是整个项目80% 的开发资源。 采用迭代化开发控制项目风险 为了解决传统软件开发流程中的问题，我们建议 采用迭代化的开发方法来取代瀑布模型。在瀑布模型 中，我们要完成的是整个软件系统开发这个大目标。 在迭代化的方 法中，我们将整个项目的开发目标划分 成为一些更易于完成和达到的阶段性小目标，这些小 目标都有一个定义明确的阶段性评估标准。迭代就是 为了完成一定的阶段 性目标而所从事的一系列开发 活动，在每个迭代开始前都要根据项目当前的状态和 所要达到的阶段性目标制定迭代计划，整个迭代过程 包含了需求、设计、实施（编 码）、部署、测试等各种 类型的开发活动，迭代完成之后需要对迭代完成的结 果进行评估，并以此为依据来制定下一次迭代的目标。 与传统的瀑布式开发模型相比较，迭代化开发具 有以下特点： 允许变更需求 需求总是会变化，这是事实。给项目带来麻烦的 常常主要是需求变化和需求〃蠕变〃，它们会导致延期 交付、工期延误、客户不满 意、开发人员受挫。通过 向用户演示迭代所产生的部分系统功能，我们可以尽 早地收集用户对于系统的反馈，及时改正对于用户需 求的理解偏差，从而保证开发出来的系统真正地解决 客户的问题。 逐步集成元素 在传统的项目开发中，由于要求一下子集成系统 中所有的模块，集成阶段往往要占到整个项目很大比 例的工作量（最 高可达40%）,这一阶段的工作经常是 不确定并且非常棘手。在迭代式方法中，集成可以说 是连续不断的，每一次迭代都会增量式集成一些新的 系统功能，要集成的元素都比过去少得多，所以工作 量和难度都是比较低的。 尽早降低风险 迭代化开发的主要指导原则就是以架构为中心， 在早期的迭代中所要解决的主要问题就是尽快确定系 统架构，通过几 次迭代来尽快地设计出能够满足核心 需求的系统架构，这样可以迅速降低整个项目的风险。 等到系统架构稳定之后，项1=1的风险就比较低了，这 个时候再去实现系统中尚未完成的功能，进而完成整 个项目。 有助于提高团队的士气 开发人员通过每次迭代都可以在短期内看到自己 的工作成果，从而有助于他们增强信心，更好地完成 开发任务。而在非迭代式开发中，开发人员只有在项 目接近尾声时才能看