17 管理变更请求

下载 第1 7章 管理变更请求 一旦执行了软件过程评估，我询问项目组成员是如何接受产品的变更需求的，其中一位 回答说“无论何时市场代表对 B r u c e或S a n d y提出变更要求，他们总是说同意，我们就只好努 力去做出来”。他并未正面回答我的问题。不被控制的变更是项目陷入混乱、不能按进度执行 或软件质量低劣的共同原因。为了使开发组织能够严格控制软件项目应确保以下事项： • 应仔细评估已建议的变更。 • 挑选合适的人选对变更做出决定。 • 变更应及时通知所有涉及的人员。 • 项目要按一定的程序来采纳需求变更。 只有项目风险承担者在开发过程中能控制变更，他们才知道将交付什么，哪一项将会导 致与目标的差距。对项目越深入了解后，你就越能发现采纳变更需求条件的苛刻。在需求文 档中一定要反映项目的变更，需求文档应精确描述要交付的产品，这就是你的原则。要是软 件需求文档同产品不一致，那它就毫无用处，甚至就象没有一个软件需求文档来指导开发组 开发一样。 当你不得不做出变更时，应该按从高级到低级的顺序对被影响的需求文档进行处理。举 个例子，一个已建议的变更可能影响一个使用实例和功能需求但不影响任何业务需求。改动 高层系统需求能够影响多个软件需求。如果在最低层需求上做出变更，（典型的情况是一个功 能性需求），可能会导致需求同上层文档不一致。 17.1 控制项目范围的扩展 Capers Jones（1 9 9 4）在 报告 软件系统测试报告下载sgs报告如何下载关于路面塌陷情况报告535n,sgs报告怎么下载竣工报告下载 中声称扩展需求对百分之八十的管理信息系统项目和百分之 七十的军事软件项目造成风险。扩展需求是指在软件需求基线已经确定后又要增添新的功能 或进行较大改动。问题不仅仅是需求变更本身，而是迟到的需求变更会对已进行的工作有较 大的影响。要是每个建议的需求都被采纳，对于项目出资者（ s p o n s o r）、参与者与客户来说项 目将永远也不会完成—事实上，这是不可能的。 对许多项目来说，一些需求的改进是合理的且不可避免。业务过程、市场机会、竞争性 的产品和软件技术在开发系统期间是可以变更的，管理部门也会决定对项目做出一些调整。 在你的项目进度表中应该对必要的需求改动留有余地。若不控制范围的扩展将使我们持续不 断地采纳新的功能，而且要不断地调整资源、进度、或质量目标，这样做极其有害。这儿一 点小的改动，那儿一点添加，很快项目就不可能按客户预期的进度和预期质量交付使用了。 管理范围扩展的第一步就是把新系统的视图、范围、限制文档化并作为业务需求的一部 分，正如第6章所描述的。评估每一项建议的需求和特性，将它与项目的视图和范围相比较决 定是否应该采纳它。强调客户参与的有效的需求获取方法能够减少遗漏需求的数量，只在做 出提交承诺和分配资源后才采纳该需求 (Jones 1996a)。控制需求扩展的另一个有效的技术是 原型法，这个方法能够给用户提供预览所有可能的实现，以帮助用户与开发者沟通从而准确 把握用户的真实需求（ Jones 1994）。 事实上，控制范围的扩展的方法是要敢于说“不” （We i n b e rg 1995）。很多人不喜欢说 “不”，开发者只好在各种压力下接受每一项建议的需求。“客户总是对的”，“我们将使客户完 全满意”这些话哲理上是正确的，一旦按此办事就要付出代价。忽视代价并不能改变“变更 不免费”的事实。我知道一个成功的商业开发公司，它的首席执行官习惯于建议新的特色但 开发管理者总是说“现在不行”。“现在不行”比简单地拒绝灵活很多，因为他暗含在后续版 本中采纳其特色的希望。把客户提出的所有特色都采纳将会导致错过提交日期，质量的下滑 （s l i p s h o d），开发人员的疲劳不堪。尽管客户并不总对，但他们是上帝，所以你应该尽可能在 下一版本中满足他们的需求。 在理想的情况下，在开始构造前应该收集到所有新系统的需求，而且在开发中基本上不 变更。这就是“瀑布”型软件开发生存期模型的前提，但在实践中，它却不太有效。当然， 某种程度上，对特定的版本应该冻结需求，不再变更。然而，很早确定需求却忽视了有时候 客户并不知道需要什么的现实，开发人员应该对用户这些需求变更作出响应。为了对付这些 实际情况，你需要有根据地采纳变更过程。 17.2 变更控制过程 一个好的变更控制过程给项目风险承担者提供了正式的建议需求变更机制。通过这些处 理过程，项目负责人（ l e a d e r）可以在信息充分的条件下做出决策，这些决策通过控制产品生 存期成本来增加客户和业务价值。你通过变更控制过程来跟踪已建议变更的状态，确保不会 丢失或疏忽已建议的变更。一旦你确定了一个需求集合的基线，你应该对所有已建议的变更 都遵循变更控制过程。 变更控制过程并不是给变更设置障碍。相反地，它是一个渠道和过滤器，通过它可以确 保采纳最合适的变更，使变更产生的负面影响减少到最小。变更过程应该做成文档，尽可能 简单，当然首要的是有效性。如果变更过程没有效率且冗长，又很复杂，大家宁愿用旧方法 来做出变更决定（或许他们应该那样做）。 控制需求变更同项目其它配置管理决策紧密相连。管理需求变更类似于跟踪错误和做出 相应决定过程，相同的工具能支持这两个活动。然而记住它是工具而不是过程。使用商业问 题跟踪工具来管理已建议的需求变更并不能代替写下变更需求的内容和处理的过程。 17.2.1 变更控制策略 项目管理应该达成一个策略，它描述了如何处理需求变更。策略具有现实可行性，要被 加强才有意义。下述需求变更的策略是有用的： • 所有需求变更必须遵循的过程，按照此过程，如果一个变更需求未被采纳，则其后过程 不再予以考虑。 • 对于未获批准的变更，除可行性论证之外，不应再做其它设计和实现工作。 • 简单请求一个变更不能保证能实现变更，要由项目变更控制委员会（ C C B）决定实现哪 些变更（本章将讨论C C B）。 • 项目风险承担者应该能够了解变更数据库的内容。 • 绝不能从数据库中删除或修改变更请求的原始文档。 140 第三部分 软件需求管理 下载 • 每一个集成的需求变更必须必须能跟踪到一个经核准的变更请求。 当然，大的变更会对项目造成显著的影响，而小的变更就可能不会有影响。原则上，应 该通过变更控制过程来处理所有的变更。但实践中，可以将一些具体的需求决定权交给开发 人员来决定。但只要变更涉及两个人或两个人以上都应该通过控制过程来处理。 有一个项目它由两大部分组成，一个是用户集成界面应用，另一个是内部知识库，但缺 乏变更过程。当知识库开发人员改变了外部界面但没有将此变更通知应用开发人员，这个项 目就碰到了麻烦。还有一个项目，开发人员在测试时才发现有人应用了新的已被修改的功能 却没有通知小组中其余人员，导致重做了测试程序和用户文档。采用统一的变更控制方法可 以避免这样的问题所带来的错误、开发的返工和耗费时间。 17.2.2 变更控制步骤 图1 7 - 1说明了一个描述一项变更控制步骤的模板，它能够应用于需求变更和其它项目变 更。下面主要讨论关于过程是如何处理需求变更的。步骤中的 4个组件和若干个过程描述将会 是很有用的： • 开始条件（entry criteria）—在执行过程或步骤前应该满足的条件。 • 过程和步骤中所包含的不同任务（ t a s k）及项目中负责完成它们的角色。 • 验证（v e r i f y）任务正确完成的步骤。 • 结束条件（exit criteria）—指出过程或步骤完成的条件。 a. 绪论 a.1 目的 a.2 范围 a.3 定义 b. 角色和责任 c. 变更请求状态 d. 开始条件 e. 任务 e.1 产生变更请求 e.2 评估变更请求 e.3 作出决策 e.4 通知变更人员 f. 验证 g. 结束条件 h. 变更控制状态报告 附录：存储的数据项 图17-1 简单变更控制步骤模板 a. 绪论 绪论主要说明此步骤（ p r o c e d u r e）的目的，并且确定了步骤能够应用的范围。如果步骤 仅仅适合特定产品中的变更，在绪论中应该明确表示。绪论还指明是否忽略特定种类的变更。 例如对于项目开发过程中产生的过渡或临时产品，我们可能忽略掉变更，同时为了理解文档 的其余部分定义了必要的条款。 b. 角色和责任 列出（按角色分类，而非姓名顺序）参与变更控制活动的项目组成员并且描述他们的责 第1 7章 管理变更请求 141 下载 任。表1 7 - 1提供了一些有关的角色。按你所处的环境和需要调整这些角色和相应的责任，在 保持有效性的前提下尽可能使过程简单。一个人不必只担任一个角色。例如，项目管理者也 可接收提交的变更需求。对于一些小项目，几个—也可能所有—角色均由一个人担任。 表17-1 变更管理活动中可能的项目角色 角 色 描述及责任 变更控制委员会主席 变更控制委员会的主席，在 C C B意见不一致情况下可 以独自做出决定 C C B 决定采纳或拒绝针对某项目所建议的变更请求的团体 评估者 应项目管理者要求 分析 定性数据统计分析pdf销售业绩分析模板建筑结构震害分析销售进度分析表京东商城竞争战略分析 所建议的变更带来影响的人员 修改者 负责实现已经被认可的请求变更，按时更新变更状态的人员 建议者 提交新变更请求的人 项目管理者 负责指定评估者和修改者的人员 请求接受者 接受提交变更请求的人 验证者 负责决定变更是否正确执行的人 c. 变更请求状态 一个变更请要求有一个生存期，相应地有不同的状态。可以使用状态转换图来表示这些 状态的变化，如图1 7 - 2所示，只有当特定条件满足时才能更新状态。 d. 开始条件 变更控制步骤的基本开始条件是： • 通过合适的渠道接受一个合法的变更请求。 所有潜在的建议者应该知道如何提交一个变更请求，是通过书面、通过基于 We b的表单、 或者发一个电子邮件，还是使用变更控制工具。将所有变更控制传递到一个联系点，且为每 一个变更请求赋予统一的标识标签。 e. 任务 接收到一新的变更要求后下一步是评估建议的技术可行性、代价、业务需求和资源限制。 变更控制委员会主席要求评估者执行一个系统影响分析（详情见第 1 8章）、风险分析、危害分 析及其它评估。这些分析确保能很好理解接受变更所带来的潜在影响。评估者和变更控制委 员会同样应考虑拒绝变更所带来的对业务和技术的影响。 制定决策的人应进入变更控制委员会，决定是采纳或还是拒绝请要的变更。 C C B给每个 采纳的变更需求设定一个优先级或变更实现日期，或将它分配给指定的产品。变更控制委员 会通过更新请求状态和通知所有涉及到的小组成员来传达变更决定。相关人员可能不得不改 变工作产品，如软件需求规格说明文档、需求数据库、设计模型、用户界面部件、代码、测 试文档、用户文档。修改者在必要时应更新涉及的工作产品。 f. 验证 验证需求变更的典型方法是通过检查确保更新后的软件需求规格说明文档、使用实例文 档、分析模型均正确反映变更的各个方面。使用跟踪能力信息找出受变更影响的系统的各个 部分，然后验证他们实现了变更（详见第 1 8章）。属于多个团组的成员可能会通过对下游工作 产品测试或检查工作来参与验证变更工作。验证后，修改者安装更新后的部分工作产品并通 过调试使之能与其它部分正常工作。 g. 退出条件 为了完成变更控制执行过程，下列退出条件应该得到满足： 142 第三部分 软件需求管理 下载 图17-2 变更需求状态转换图 • 请求的状态为“拒绝”，“结束”或“取消”。 • 所有修改后的工作产品安装至合适的位置。 • 建议者，变更控制主席，项目管理者和其他相关的项目参与者已经注意到了变更的细节 和当前的状态。 • 已经更新需求跟踪能力矩阵（详见第 1 8章）。 h. 变更控制状态报告 用报告、图表来总结变更控制数据库的内容和按状态分类的变更请求数量。描述产生报 告的步骤。项目管理者通常使用这些报告来跟踪项目状态。 附录：存储的数据项 表1 7 - 2列出了每一个变更请求存储的一些数据项。当定义自己的列表时，指出什么是必 选项，什么是可选项。同时指出每一项的值是由变更控制工具自动修正还是由指定的人员手 第1 7章 管理变更请求 143 下载 建议着提交一 个变更请求 评估者进行 影响分析 CCB决定接受变更，分配一个版 本，指派给一个修改者 修改者接受变 更并请求校验 完成提交 完成评估 被拒绝CCB决定 不作变更 被采纳 变更被取消 变更被取消 已取消 变更被取消 修改者已安装产品 验证者已 确认变更 实施变更 验证 没有验证请 求，修改者已 安装产品 验证失败 结束 工修正。有经验后可能喜欢自己修正数据项，所以当你使用电子表格或一张纸实验处理过程 后，再让自动工具着手这事。 表17-2 常见变更请求数据项 数据项名称 定 义 变更由来 请请求变更的功能区域，可能包括的团体，有市场、管理、客户、软件工程、 硬件工程和测试 变更要求 I D号 请分配给每个请求的标签或顺序号 变更类型 请变更请求的类型，例如需求变更，建议性增改，错误报告 提交日期 请提交变更请求的日期 更新日期 请最近更新变更请求的日期 描述 请以自由格式文本描述已请求的变更 实现优先级 请由变更控制委员会赋予的每个变更的相对重要性，例如低、中、高 修改者 请实现变更的主要负责人姓名 建议者 请提交变更请求的人名，也可以存储与此人相关的信息 建议者设置的优先级 请建议者赋予每个变更的相对重要性，例如：低，中，高 实现版本 请计划中实现此变更的产品版本号 项目 请要求变更的项目名称 反映文档 请与每个变更相对应的反映文档，可以做出各种反映文档，所有反映文档均应 保留 状态 请变更请求的当前状态。可以从图 1 7 - 2中选择相应状态 标题 请对变更的简短总结（最好仅一行） 验证者 请负责决定是否正确实现变更的人名 17.2.3 变更控制工具 自动工具能够帮助你有效地执行变更控制过程（ Wiegers 1996a）。有许多人使用商业问题 跟踪工具来收集、存储、管理需求变更。可以使用这些工具对一系列最近提交的变更建议产 生一个列表给变更控制委员会开会时做议程用。问题跟踪工具也可以随时按变更状态分类报 告变更请求的数目。 我曾参与了一个 We b开发组，我们使用高级配置的问题管理工具来存储软件需求变更请 求、问题报告、建议的产品增强、更新 We b站点内容及新开发项目请求。由于工具的功能、 经销商总是频繁变更，所以我给不出任何具体的建议。但有一个关于软件工具信息的好站点， 地址是h t t p：/ / w w w. m e t h o d s - t o o l s . c o m。挑选工具时可以考虑以下几个方面： • 可以定义变更请求的数据项。 • 可以定义变更请求生存期的状态转换图。 • 可以加强状态转换图使经授权的用户仅能做出所允许的状态变更。 • 记录每一种状态变更的数据，确认做出变更的人员。 • 可以定义在提交新请求或请求状态被更新后应该自动通知的设计人员。 • 可以根据需要生成标准的或定制的报告和图表。 一些商业需求管理工具（详见第 1 9章）内置有简单的变更建议系统。这些工具可以通过 联系链从建议变更找到特定的需求，使得任何时候，无论谁作出变更请求，均可以通过 e - m a i l 及时通知涉及到的人员。 144 第三部分 软件需求管理 下载 17.3 变更控制委员会 软件开发活动中公认变更控制委员会或 C C B（有时也称为结构控制委员会）为最好的策 略之一（McConnell 1996）。变更控制委员会可以由一个小组担任，也可由多个不同的组担任， 负责做出决定究竟将哪一些已建议需求变更或新产品特性付诸应用。典型的变更控制委员会 同样决定在哪一些版本中纠正哪一些错误。许多项目已经有负责变更决策的人员，而正式组 建变更控制委员、制定操作步骤会使他们更有效地工作。 广义上，变更控制委员会对项目中任何基线工作产品的变更都可做出决定，需求变更文 档仅是其中之一。大项目可以有几级控制委员会，有些负责业务决策（例如需求变更），另一 些负责技术决策（Sorensen 1999）。有些变更控制委员会可以独立做出决策，而有些只是负责 决策的建议工作。高级变更控制委员会做出的决策对计划的影响应比低级的大。小项目中， 只需一两个人就可做出所有决策。 看到“变更控制委员会”这个词组，会使某些人想到一群高高在上而且浪费时间的官僚 分子。然而，应该想到有变更控制委员会的企业结构可以帮助你很好地管理项目，哪怕是一 个小项目。这个结构并不浪费时间或是累赘，相反会很有效率。一个有效率的变更控制委员 会定期地考虑每个变更请求，并且基于对由此带来的影响和获益做出及时的决策。变更控制 委员会只要能让合适的人做正确的事就足够了，不必追求大而全。 17.3.1 变更控制委员会的组成 变更控制委员会的成员应能代表变更涉及的团体。变更控制委员会可能包括如下方面的 代表： • 产品或计划管理部门。 • 项目管理部门。 • 开发部门。 • 测试或质量保证部门。 • 市场部或客户代表。 • 制作用户文档的部门。 • 技术支持部门。 • 帮助桌面或用户支持热线部门。 • 配置管理部门。 对于小项目只需几个人充当其中的一些角色就可以，并不一定要面面俱到。组建包含软、 硬件两方面的项目的变更控制委员会时，也要包括来自硬件工程、系统工程、制造部门或者 硬件质量保证和配置管理的代表。建立变更控制委员会在保证权威性的前提下应尽可能精简 人员。大团队可能很难碰头和做出决策。确保变更控制委员成员明确担负的责任。有时为了 获得足够的技术和业务信息，也可以邀请其他人员参加会议。 17.3.2 变更控制委员会总则 设立变更控制委员会的第一步是写一个总则，描述变更控制委员会的目的、授权范围、 成员构成、做出决策的过程及操作步骤（ Sorensen 1999）。总则也应该说明举行会议的频度和 第1 7章 管理变更请求 145 下载 事由。管理范围是指该委员会能做什么样的决策，及哪种决策应上报到高一级的委员会。 1. 制定决策 制定决策过程（程式）的描述应确认： • 变更控制委员会必须到会的人数或作出有效决定必须出席的人员数。 • 决策的方法，例如：投票、一致通过或其它机制。 • 变更控制委员会主席是否可以否决 C C B的集体决定。 变更控制委员会应该对每个变更权衡利弊后做出决定。“利”包括节省的资金或额外的收 入、增强的客户满意度、竞争优势、减少上市时间。“弊”是指接受变更后产生的负面影响， 包括增加的开发费用、推迟的交付日期、产品质量的下降、减少的功能、用户不满意。如果 估计的费用超过了本级变更控制委员会的管理范围，上报到高一级的委员会，否则用制订的 决策程式来对变更做出决定。 2. 交流情况 一旦变更控制委员会做出决策时，指派的人员应及时更新数据库中请求的状态。有的工 具可以自动通过电子邮件来通知相关人员。若没有这样的工具，就应该人工通知，以保证他 们能充分处理变更。 3. 重新协商约定 变更总是有代价的。即使拒绝的变更也因为决策行为（提交、评估、决策）而耗费了资 源。变更对新的产品特性会有很大的影响。向一个工程项目中增加很多功能，又要求在原先 确定的进度计划、人员安排、资金预算和质量要求限制内完成整个项目是不现实的。当工程 项目接受了重要的需求变更时，为了适应变更情况要与管理部门和客户重新协商约定 （Humphrey 1997）。协商的内容可能包括：推迟“交货”时间、要求增加人手、推迟实现尚未 实现的较低优先级的需求，或者质量上进行折衷。要是不能获得一些约定的调整，应该把面 临的威胁写进风险管理计划中，这样当项目没有达到期望的结果时就不会有人惊奇了。 17.4 测量变更活动 软件测量是深入项目、产品、处理过程的调查研究，比起主观印象或对过去发生事情的 模糊回忆要精确得多。测量方法的选择应该由所面临的问题和要达到的目标为依据。测量变 更活动是评估需求的稳定性和确定某种过程改进时机（ o p p o r t u n i t y）的一种方法，这种时机 可以减少未来的变更请求。需求变更活动的下列方面值得考虑（ CMU/SEI 1995）： • 接收、未作决定、结束处理的变更请求的数量。 • 已实现需求变更（包括增、删、改）的合计数量（也可以用在基线上占需求总数的百分 比来表示）。 • 每个方面发出的变更请求的数量。 • 每一个已应用的需求（是指已划过基线）建议变更和实现变更的数量。 • 投入处理变更的人力、物力。 可以先用简单的测量法在组织中建立氛围，同时收集有效管理项目所需的关键数据。获 得经验后就可以建立复杂的测量方法来管理项目。 图1 7 - 3说明了在开发过程中跟踪需求变更数目的一种方法。这个图跟踪新的需求变更建 议出现的速率，类似地，还可跟踪采纳的变更需求数量。因为需求在不断变化，所以不必在 146 第三部分 软件需求管理 下载 定基线前知道实现的变更需求数量。然而，一旦划好了需求基线，应遵循变更控制过程来处 理建议的变更，并开始跟踪变更的频率（需求的稳定性）。这种图表的最终趋势应为零。持续 高频率的变更隐含了项目超期的风险。同样也表明原来需求的基线确定不完善，应该改进需 求获取的策略。 一个项目管理者应该知道频繁的需求变更会使产品不能按时交付。可以通过跟踪产生需 求变更的来源深入剖析这个问题。图 1 7 - 4说明了按来源分类的变更请求数量。项目管理者通 过图1 7 - 4应该了解到销售部门造成的需求变更最多。这样，项目管理者就可以与市场代表和 项目组一起讨论采取何种措施来减少销售部门提出的变更请求。以数据作为这种讨论的出发 点比盲目地开一些面对面的会议更有建设性。 图17-3 需求变化活动的样本图 图17-4 需求变更起源的样本图 现实中的软件项目均有需求变更。严格控制变更管理策略可以减少变更造成的混乱，改 第1 7章 管理变更请求 147 下载 划分基线SRS数周之后 建 议 变 更 数 建 议 的 变 更 范 围 变更起源 市场 管理 客户 软件工程 硬件工程 测试 进的需求开发技术可以减少面临的需求变更的数量。效率高的需求获取和管理策略将增强按 时交付的能力。 下一步： • 确定决策制订者并且建立一个变更控制委员会。制订变更委员会的总则，使每个人 都理解变更控制委员会的目的、组成及决策制订过程。 • 参见图1 7 - 2，为项目建议的需求变更生存期制订一个状态转换图。制定一个描述项 目组如何处理建议变更的过程。手工地使用这些过程，直到你确信它是实用的、有 效的，并且简单到你能成功使用为止。 • 选择合适的商业问题跟踪工具，它们能与你所处的环境密切配合并且通过裁剪工具 使可以支持以前开发出的变更控制过程。 148 第三部分 软件需求管理 下载 第1 7 章管理变更请求 17.1 控制项目范围的扩展 17.2 变更控制过程 17.2.1 变更控制策略 17.2.2 变更控制步骤 17.2.3 变更控制工具 17.3 变更控制委员会 17.3.1 变更控制委员会的组成 17.3.2 变更控制委员会总则 17.4 测量变更活动