《软件需求--第5章软件需求与风险管理》青少年教育丛书.pdfVIP

下载 第5章 软件需求与风险管理 负责C o n t o s o制药公司“化学制品跟踪系统”的项目管理人员 D a v e会见他的首席 程序员H e l e n和首席测试员R a m e s h 。他们对新项目都很有兴趣，但他们也记得在以前 一个称作“药品仿真”的项目中遇到的问题。 “还记得我们直到进入测试时才发现用户对仿真程序的用户界面极为不满意 吗？”H e l e n 问道。 “我们花了五周时间重新实现，重新测试，我可再不愿玩这样的 死亡游戏了。” “的确是烦人，”D a v e 附和道。“同样麻烦的是那些用户提出一大堆没人用过的特 性，这样的交互导致编码花费了预计时间的三倍，我们是不管好歹，编完了事，简 直是废品！” “我们太匆忙了，以至没有时间写详细的需求说明”R a m e s h 回忆道。“测试人员 有一半的时间都在问程序员怎样才能判断他们的程序工作正常，以便能测试它。可 是程序员设计的一些功能根本就不是用户所要求的。” “特别麻烦的是，要求开发药品仿真的管理者根本没有看需求规格说明就在上面 签字确认了。”D a v e补充道：“于是我们不断遇到要求新的特性及各种变更，所以工 程超期四个月，成本费用超出预算的一倍这也就不足为怪了。若再发生这样的事， 我肯定会被解雇了。” R a m e s h建议道：“也许我们应该把在仿真项目中遇到的问题一一列出来以便我们 能在化学制品跟踪系统中避免重蹈覆辙。我看了篇关于软件风险管理的文章，上面 介绍说我们应指出各种风险并说明了怎样才能避免它们”。 “我可不那样想”D a v e 坚持道：“我们已从仿真项目学到了不少，我们不会再有 那些问题了。这个项目还没有达到需要用风险管理的地步。如果要把我们可能犯的 错误都写下来，好像我连怎样做软件项目都不知道似的。我不想要任何消极想法影 响项目。我们必须为成功而制定计划。” 正如D a v e 的最后一句话所反映的那样，软件工程师都是绝对的乐观主义者。我们总是希 望我们的下一个项目进行顺利，而忽略以前项目发生的问题。事实却是许多潜在威胁阻碍项 目按计划进行。与D a v e 的想法恰恰相反的是，软件项目管理者必须要明确和控制他们的项目 风险，并且要从需求工程的风险开始进行。 所谓风险是可能给项目的成功带来威胁或损失的情况。这种情况还没有发生，也没有带 来问题，而你希望它永远不会发生。但这些潜在的问题可能会给项目成本费用、进度安排、 技术方面、产品质量及团队工作效率等带来较大的负面影响。而风险管理—一种软件工业 的最佳方法—就是在风险给项目带来损失之前，就指明、评估并对风险加以控制。如果不 希望发生的事已经发生了，那就不再是风险，而是事实了。只好通过项目事务 ( o n g o i n g )状态 跟踪和校正过程来处理当前的问题。 正如没有人能确切地预测未来，风险管理也仅是让你采取一些措施尽可能减少潜在问题 38 第一部分 软件需求：是什么和为什么 下载 发生的可能性或减少其带来的影响。风险管理的意思是在一种担忧转变为危机或实际困难之 前处理它。这将提高项目成功的可能性且可减少不可避免的风险造成的损失。对处于个人控 制领域之外的风险应由相应层次的管理者来负责。 由于需求说明在软件项目中扮演着一个核心的角色，故精明的项目管理者会在初期就指 明与需求相关的风险并积极地控制它们。典型的需求风险包括对需求的误解、不恰当的用户 参与、不确定或随意变更项目的范围和目标以及持续变更需求。项目管理者只能通过与客户、 或客户代表（如市场人员）的合作来控制需求风险。合作编写需求风险文档，共同制定减轻 风险的措施，增强客户与开发人员之间的合作伙伴关系，这在第 2章中已作介绍了。 不仔细研究是不能把风险撵走的，因此本章对需求风险管理进行简略的介绍。本章后面还 会提到需求工程中常出现的一些风险因素。运用这些信息可以使你在风险攻击项目前处理风险。 5.1 软件风险管理基础 除了与项目范围和需求有关的风险外，项目还面临着许多风险。依赖于外界实体，例如 一个转包承揽者或生产重用部件的另一个项目就是一