第17章管理变更请求解析.PDFVIP

下载 第1 7章 管理变更请求 一旦执行了软件过程评估，我询问项目组成员是如何接受产品的变更需求的，其中一位 回答说“无论何时市场代表对 B r u c e 或S a n d y提出变更要求，他们总是说同意，我们就只好努 力去做出来”。他并未正面回答我的问题。不被控制的变更是项目陷入混乱、不能按进度执行 或软件质量低劣的共同原因。为了使开发组织能够严格控制软件项目应确保以下事项： • 应仔细评估已建议的变更。 • 挑选合适的人选对变更做出决定。 • 变更应及时通知所有涉及的人员。 • 项目要按一定的程序来采纳需求变更。 只有项目风险承担者在开发过程中能控制变更，他们才知道将交付什么，哪一项将会导 致与目标的差距。对项目越深入了解后，你就越能发现采纳变更需求条件的苛刻。在需求文 档中一定要反映项目的变更，需求文档应精确描述要交付的产品，这就是你的原则。要是软 件需求文档同产品不一致，那它就毫无用处，甚至就象没有一个软件需求文档来指导开发组 开发一样。 当你不得不做出变更时，应该按从高级到低级的顺序对被影响的需求文档进行处理。举 个例子，一个已建议的变更可能影响一个使用实例和功能需求但不影响任何业务需求。改动 高层系统需求能够影响多个软件需求。如果在最低层需求上做出变更，（典型的情况是一个功 能性需求），可能会导致需求同上层文档不一致。 17.1 控制项目范围的扩展 Capers Jones （1 9 9 4）在报告中声称扩展需求对百分之八十的管理信息系统项目和百分之 七十的军事软件项目造成风险。扩展需求是指在软件需求基线已经确定后又要增添新的功能 或进行较大改动。问题不仅仅是需求变更本身，而是迟到的需求变更会对已进行的工作有较 大的影响。要是每个建议的需求都被采纳，对于项目出资者（ s p o n s o r ）、参与者与客户来说项 目将永远也不会完成—事实上，这是不可能的。 对许多项目来说，一些需求的改进是合理的且不可避免。业务过程、市场机会、竞争性 的产品和软件技术在开发系统期间是可以变更的，管理部门也会决定对项目做出一些调整。 在你的项目进度表中应该对必要的需求改动留有余地。若不控制范围的扩展将使我们持续不 断地采纳新的功能，而且要不断地调整资源、进度、或质量目标，这样做极其有害。这儿一 点小的改动，那儿一点添加，很快项目就不可能按客户预期的进度和预期质量交付使用了。 管理范围扩展的第一步就是把新系统的视图、范围、限制文档化并作为业务需求的一部 分，正如第6章所描述的。评估每一项建议的需求和特性，将它与项目的视图和范围相比较决 定是否应该采纳它。强调客户参与的有效的需求获取方法能够减少遗漏需求的数量，只在做 出提交承诺和分配资源后才采纳该需求 (Jones 1996a) 。控制需求扩展的另一个有效的技术是 原型法，这个方法能够给用户提供预览所有可能的实现，以帮助用户与开发者沟通从而准确 140 第三部分 软件需求管理 下载 把握用户的真实需求（ Jones 1994 ）。 事实上，控制范围的扩展的方法是要敢于说“不” （We i n b e rg 1995 ）。很多人不喜欢说 “不”，开发者只好在各种压力下接受每一项建议的需求。“客户总是对的”，“我们将使客户完 全满意”这些话哲理上是正确的，一旦按此办事就要付出代价。忽视代价并不能改变“变更 不免费”的事实。我知道一个成功的商业开发公司，它的首席执行官习惯于建议新的特色但 开发管理者总是说“现在不行”。“现在不行”比简单地拒绝灵活很多，因为他暗含在后续版 本中采纳其特色的希望。把客户提出的所有特色都采纳将会导致错过提交日期，质量的下滑 （s l i p s h o d ），开发人员的疲劳不堪。尽管客户并不总对，但他们是上帝，所以你应该尽可能在 下一版本中满足他们的需求。 在理想的情况下，在开始构造前应该收集到所有新系统的需求，而且在开发中基本上不 变更。这就是“瀑布”型软件开发生存期模型的前提，但在实践中，它却不太有效。当然， 某种程度上，对特定的版本应该冻结需求，不再变更。然而，很早确定需求却忽视了有时候 客户并不知道需要什么的现实，开发人员应该对用户这些需求变更作出响应。为了对付这些 实际情况，你需要有根据地