软件工程实施的个重要思想.doc

6.8 小结　　当对软件项目期望很高时，一般都会进行风险分析。不过，即使他们进 行这项工作，大多数软件项目管理者都是非正式地和表面上地完成它。花在 标识、分析、和管理风险上的时间可以从多个方面得到回报：更加平稳的项　　目进展过程；较高的跟踪和控制项目的能力；由于在问题发生之前已经做了 周密计划而产生的信心。　　风险分析需要占用大量项目计划的工作量。标识、预测、评估、管理、 及监控都要花费时间。但这是值得的。引用中国 2500 多年前的兵法家孙子的 话：“知己知彼，百战不殆”。对于软件项目管理者而言，这个“彼”指的 就是风险。思考题6.1 举出五个其他领域的例子来说明与被动风险策略相关的问题。6.2 描述“已知风险”和“可预测风险”之间的差别。　　6.3 在本章给出的所有风险检查表中的条目中增加三个额外的问题或主 题。　　6.4 你被要求建造一个软件以支持一个低成本的视频编辑系统。该系统 将录像带作为输入设备，将视频信息存在磁盘上，并允许用户对已经数字化 的视频信息进行各种编辑。对这类系统做一些调研，然后列出当你开始启动 该项目以建造视频编辑系统时，你将面临的技术风险是什么。6.5 你是一家大型软件公司的项目管理者。你被要求领导一个小组开发“下一代”字处理软件(见 3.3.2 节的简单描述)。为该项目建立一个风险表。6.6 描述风险因素和风险驱动因子之间的不同。6.7 为项目风险驱动因子建立一个加权方案。6.8 为图 6－2 中的三个风险建立风险缓解策略及特定的风险缓解活动。　　6.9 为图 6－2 中的三个风险建立风险监控策略及特定的风险监控活动。 确认你已经标识出了你需要监控的因素，并确定风险发生的可能性是否在变 高或变低。6.10 为图 6—2 中的三个风险建立风险管理策略及特定的风险管理活动。　　6.11 你能否想到一种情况：一个高概率、高影响的风险并不纳入 RMMM 计划的考虑之中？6.12 参照图 6－4 所示的风险参考水平值，该曲线是否总是如图显示的那么匀称光滑，或者是否会有该曲线扭曲变形的情况存在？如果有，请举出 一个例子。6.13 做一些关于软件安全方面的研究，并写一份简单的报告。可以参考［LEV95］做为起点。6.14 描述五个软件安全和危险分析是主要关心对象的软件应用领域。第 7 章 项目进度安排及跟踪　　在六十年代后期，一位热情的青年工程师①受命为一个自动制造应用软件 项目“编写”计算机程序。选择他的原因非常简单，因为在整个技术小组中 他是唯一参加过计算机编程培训班的人。这位工程师对汇编语言的 IN 和 OUT 指令以及 Fortran 语言略知一二，但是却根本不懂软件工程，更不用说项目 进度安排和跟踪了。　　他的老板给了他一大堆相关的手册，以及需要做些什么的口头描述。年 轻人被告知该项目必须在两个月之内完成。　　他阅读了这些手册，想好了解决方法，就开始编写代码。两周之后，老 板将他叫到办公室询问项目进展情况。　　“非常好，”工程师以年轻人的热情回答道，“这个项目远比我想象的 简单。我差不多已经完成了 75％的任务。”　　老板笑了，说道：“真是太棒了。”然后他嘱咐年轻人继续努力工作， 准备好一周后再汇报一次工作进度。一周之后老板将年轻人叫到办公室，问他说：“现在进度如何？” “一切顺利，”年轻人回答说，“但是我遇到了一些小麻烦。我会排除这些困难，很快就可以回到正轨上来。”“你觉得在最后期限之前能否完成？”老板问道。 “没有问题，”工程师答道。“我差不多已经完成了 90％。” 如果读者在软件领域中工作过几年，你一定可以将这个故事写完。毫不奇怪，青年工程师在整个项目工期内始终停留在 90％的进度上，(在别人的帮助下)直到交付期限之后一个月才做完。　　在过去的 30 年间，这样的故事被不同的软件开发者重复了成千上万次。 我们不禁要问：“为什么？”7.1 基本概念　　虽然软件延期交付的原因很多，但是大多数都可以追溯到下面列出的一 个或多个根本原因上：·一个不现实的截止期限，由软件工程组以外的人所设立并强加给软件工程组内的管理者和项目开发者。·客户需求发生变化，而需求的变化没有能够反映在项目进度的变化上。·对工作量和/或完成该工作所需的资源数量估计不足。·在项目开始时，没有将可以预测的和/或不可预测的风险考虑在内。·事先无法预计的技术困难。·事先无法预计的人力困难。·由于项目组成员之间的交流不畅而导致的延期。·项目管理者未能发现进度拖后，也未能采取行动解决这一问题。 在软件行业中，人们对过于乐观的(即“不现实的”)项目完成期限已经司空见惯。有时候设定截止时间的人认为这样的截止期限是合理的，但是常 识告诉