第21章 管理变更.ppt

第21章 管理变更 对待软件项目管理的组织必须确保做到以下几点： 在提交提议的需求变更之前要对其进行仔细的评估。 请合适的人员就需求变更做出周全合理的业务决策。 将已批准的变更传达给受此影响的所有人员。 项目以一致的方式将需求变更包含进来。 采用一致的变更控制方法，就可以避免相关问题，避免开发工作的返工和浪费时间等情况的发生。 变更控制委员会 变更控制委员会，有时也称为配置控制委员会(configuration control board，CCB)，已被证实是软件开发领域公认的最佳实践(McConnell 1996)。 CCB是由人组成的团体，可以由一个小组担任，也可以由多个不同的小组担任，这些人共同决定将哪些已提议的需求变更和新提议的特性在产品中付诸实现。 CCB也决定所报告的缺陷中哪些需要纠正，什么时候纠正。 CCB可以评审和批准对项目中任何基线工作产品所做的变更，项目需求文档只是其中的一个样例。 CCB的组成 CCB的成员应该能代表需要参与制定决策的所有小组，当然这些决策制定只能是在CCB的权力范围之内。 可考虑从下面这些部门中选择CCB代表： 项目或程序管理部门 产品管理或需求分析部门 开发部门 测试或质量保证部门 市场或客户代表 编写用户文档的部门 技术支持或帮助部门 配置管理部门 CCB规章 CCB规章描述了CCB的目的、权力范围、成员构成、运作规程和决策的制定过程等(Sorensen 1999)。 CCB的权力范围规定了哪些决策由CCB决定，哪些决策则必须上报给高一级CCB或者由管理层来决定。 1. 制定决策 决策制定过程的描述应该确定： CCB成员或主要角色的人数，这是制定决策的法定人数。 所采用的决策规则是投票、少数服从多数、协商决定或其他方法。 CCB规章 CCB主席是否可以否决CCB的集体决策。 级别高的CCB或其他人是否必须认可CCB做出的决策。 2. 交流状态 CCB做出决策之后，应该指派专人对变更数据库中的变更请求状态进行更新。 3. 重新协商原先的约定 在接受一个重大的需求变更之前，为了适应这一变更，需要同管理部门和客户重新协商原先的约定(Humphrey 1997)。 协商的内容可能包括，要求推迟产品交付时间，要求增派人手，或者要求推迟实现尚未实现的优先级较低的需求等。 测量变更活动 选择测量方法时应该以您或管理层要回答的问题，以及力图要达到的目标为依据。 测量变更活动是评估需求稳定性的一种方法，它也揭示了是否可能通过过程改进来减少以后的变更请求。 应该考虑需求变更活动的以下几个方面(Paulk et al. 1995)： 接收、未作决定和已结束处理的变更请求的数量。 变更的累计数量，包括增加、删除和修改的需求。 每个部门所提议的变更请求数。 已确定为基线需求后，每个需求中提议的变更和实现的变更的数目。 处理和实现变更请求所投入的总工作量。 正确实现每一个已批准的变更所经过的变更过程的反复次数。 变更需要付出代价：影响分析 对软件实施大的功能增强，则需要进行影响分析(impact analysis)。但是，即使是小的变更请求，也可能潜伏着难以预料的复杂性。 影响分析是需求管理的一个关键方面(Arnold和Bohner 1996)。 通过对影响进行分析，可以准确地理解提议的变更所涉及到的问题，有助于项目团队就批准哪些提议做出周全合理的业务决策。 影响分析通过对所提议的变更进行检查，确定可能必须创建、修改或废弃哪些部分，并估计与实现这些变更相关的工作量。 影响分析的过程 影响分析有3个方面： 1.理解进行变更可能涉及的问题。变更常常会产生大量的连锁反应，产品包括的功能太多会降低其性能，甚至会到令人难以接受的地步。 2.确定如果团队将提议的变更包括到产品中，可能必须对哪些文件、模型和文档进行修改。 3.确定实现变更所需执行的任务，并估计完成这些任务所需的工作量。 影响分析报告模板 图是一个推荐的报告模板，表示对每个需求变更造成的潜在影响的分析结果。如果采用标准模板，CCB成员就可以轻松地找到他们所需的信息，作出合理的决策。 有效的需求变更过程。 需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。如果变更被接受，还要增加实施变更和验证两个步骤，有时还会有取消变更的步骤。 配置管理是管理需求的一个必要方面。 基线是软件开发中的里程碑，其标志是有一个或多个软件配置项的交付，且已经经过正式技术评审而获得认可。 需求变更的原因 需求变更的恶性循环 需求变更的因素 需求变更的代价 减少需求变更 需求变更的过程管理 认识到变更不可避免，为变更制订计划。 确认需求基线。 建立控制变更的唯一渠道。 使用变更控制系统来捕获变更。 分层次地管理变更。 变更请求流程 分层次的需