第21章管理变更.ppt

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