软件需求与分析教程（第十九章）.pptVIP

第19章 变 更 管 理 对待软件项目管理的组织必须确保做到以下几点： 在提交提议的需求变更之前要对其进行仔细的评估。 请合适的人员就需求变更做出周全合理的业务决策。 将已批准的变更传达给受此影响的所有人员。 项目以一致的方式将需求变更包含进来。 采用一致的变更控制方法，就可以避免相关问题，避免开发工作的返工和浪费时间等情况的发生。 19.1 管理范围蔓延 需求的蔓延主要会对以下各项造成较高风险： 80%的管理信息系统项目。 70%的军事软件项目。 45%的外包软件项目。 需求蔓延包括在项目需求已经纳入基线之后又提出新功能和重大修改。 19.1 管理范围蔓延 管理范围蔓延的第1步是将新系统的前景、范围和局限性作为业务需求的一部分编写成文档，请参见第5章的介绍。 原型是控制范围蔓延的又一种有效技术(Jones 1994)，通过原型可以预先了解产品可能的实现，这有助于开发人员和用户对用户需要和预期的解决方案有一个一致的理解。 控制范围蔓延的最有效的技术是要敢于说“不”(Weinberg 1995)。 19.2 变更控制过程 项目负责人通过变更控制过程，可以做出周全的业务决策，这些决策在控制产品生命周期成本的同时，可以提供最高的客户价值和业务价值。 通过这一过程跟踪所有已提议变更的状态，这有助于不会丢失或忽视已建议的变更。 将一组需求集纳入基线之后，对这一基线提出的所有变更都应该遵循这一过程。 更控制过程并不是做出必要修改的障碍，而是一个漏斗和过滤机制，可以确保项目将最合适的需求包含进来。 将变更过程详细地编写成文档，尽可能简单，当然首先是要有效。 19.2.1 变更控制策略 管理层应该明确地传达一个策略，具体陈述项目团队应该如何处理提议的需求变更。 下面这些变更控制策略是很有用的： 所有需求变更都应遵循这一控制过程。如果提交变更请求的过程与此过程不符，则不予考虑。 对于未获批准的变更，除可行性研究之外，不应再做其他设计和实现工作。 19.2.1 变更控制策略 简单地提出一个变更请求并不意味该变更肯定能够实现，应由项目的变更控制委员会(change control board，CCB)决定实现哪些变更所有涉众都能够了解变更数据库的内容。 绝不能修改或删除变更请求的原始文本。 对每一个变更都应该进行影响分析。 包含的每一个需求变更必须都能追溯到一个已获得批准的变更请求。 对批准或否决每一个变更请求的理由都要进行记录。 19.2.2 变更控制过程描述 图19.1演示了一个变更控制过程描述的模板，可用来处理需求变更和其他项目的变更。 下面几个部分包含在所有步骤和过程描述中是有益的： 开始条件——在执行过程或步骤之前必须满足的条件。 过程或步骤所涉及的各种任务，负责每个任务的项目角色，以及任务的其他参与者。 验证任务是否正确完成的步骤。 结束条件——表明满足什么条件、过程或步骤可以说是成功完成了。 19.2.2 变更控制过程描述 1. 概述 这一部分描述了变更控制过程的目的，并确定了这一过程所应用的组织范围。 2. 角色和职责 按角色而不是按姓名列出参与变更控制活动的项目团队成员，并描述他们的职责。 3. 变更请求状态 变更请求要有一个定义的生命周期，在生命周期的每一个阶段有不同的状态。 4. 开始条件 变更控制过程基本的开始条件是：通过正式的渠道接收到一个有效的变更请求。 19.2.2 变更控制过程描述 5. 任务 下一步是评估变更请求的技术可行性、费用以及项目的业务需求和资源限制。 6. 验证 需求变更通常是通过同级评审进行验证的，以确保修改后的规格说明、用例和模型正确地反映了变更的各个方面。 7. 结束条件 要结束变更控制过程，必须满足下列所有条件： 请求的状态只能是“已否决”、“已结束”或“已取消”。 所有修改过的工作产品均已安装到合适的位置。 已经将变更细节和变更请求的当前状态通知了提议者、CCB主席、项目经理和其他相关的项目参与者。 需求的跟踪矩阵已得到更新。 19.2.2 变更控制过程描述 8. 变更控制状态报告 确定用哪些图表和报告来总结变更控制数据库的内容。 附录：每个请求所需要存储的数据项 具体定义这一清单时，需要说明哪些数据项是必须的，哪些数据项是可选的，还要说明每个数据项的值是由变更控制工具自动设置的，还是由某一变更管理参与者手工设置的。 19.3 变更控制委员会 变更控制委员会，有时也称为配置控制委员会(configuration control board，CCB)，已被证实是软件开发领域公认的最佳实践(McConnell 1996)。 CCB是由人组成的团体，可以由一个小组担任，也可以由多个不同的小组担任，这些人共同决定将哪些已提议的需求变更和新