发布时间 : 星期二 文章软件项目管理与案例分析思考题及答案更新完毕开始阅读
2) 技术风险（technical risk）威胁到要开发软件的质量及交付时间。
技术风险指设计、实现、接口、验证和维护等方面的问题。此外，规格说明的歧义性、技术的不确定性、陈旧的技术以及“前沿”技术也是技术风险因素。 3) 商业风险（business risk）威胁到要开发软件的生存能力，且常常会危害到项
目或产品。
五个主要的商业风险是：
(1)开发了一个没有人真正需要的优秀产品或系统(市场风险)； (2)开发的产品不再符合公司的整体商业策略(策略风险)； (3)开发了一个销售部门不知道如何去销售的产品（销售风险）；
(4)由于重点的转移或人员的变动而失去了高级管理层的支持(管理风险)； (5)没有得到预算或人员的保证(预算风险)。 2. 我们正在进行的软件项目面临严重的风险吗？
3. 如何评估风险产生的后果？
如果风险真的发生了，有三个因素可能会影响风险所产生的后果，即风险的性质、范围和时间。
以下的步骤被建议用来确定风险的整体影响： 1) 确定每个风险因素发生的平均概率。 2) 确定每个因素的影响。 3) 填写风险表，并分析其结果。
4. 用什么好的方式来描述风险？
按条件－转化－结果（condition-transition-consequence,CTC）格式来表示风险，即采用如下方式来描述风险：
给定<条件>，则（可能）将导致：<结果>
5. 如何缓解风险？
为了缓解这个风险，项目管理者必须制定一个策略来减少人员变动。可能采取的步骤包括：
1) 与现有人员一起探讨人员变动的起因（如恶劣的工作条件、报酬低、竞争激
烈的劳动力市场）。
2) 在项目开始之前采取行动，设法缓解那些我们能够控制的起因。
3) 项目启动之后，假设会发生人员变动，当人员离开时，找到能够保证工作连
续性的方法。
4) 组织项目团队，使用得每一个开发活动的信息能被广泛传播和交流 5) 制定工作产品标准，并建立相应机制以确保能够及时创建所有的模型和文
档。
6) 同等对待所有工作的评审（使得不止一个人能够“跟上进度”）。 7) 给每个关键的技术人员都指定一个后备人员。 小结：
对软件项目期望很高时，一般都会进行风险分析。不过，即使进行这项工作，大多数软件项目管理者都是非正式地和表面上地完成它。花在识别、分析和管理风险上的时间可以从多个方面得到回报：更加平稳的项目进展过程；较高的跟踪和控制项目的能力；在问题发生之前已经做了周密计划而产生的信心。
风险分析需要占用大量项目计划的工作量。识别、预测、评估、管理和监测都要花费时间。但这是值得的。引用中国2500多年前的军事家孙子的一句话：“知己知彼，百战不殆”。对于软件项目管理者而言，这个“彼”指的就是风险。
第七章 思考题
1、什么是软件质量控制？
质量控制是为了保证每一件工作产品都能满足对它的需求而应用于整个开发周期中的一系列审查、复审和测试。
质量控制在创建工作产品的过程中包括一个反馈循环。测量和反馈相结合，使得我们能够在得到的工作产品不能满足其规格说明时调整开发过程。
质量控制中的关键概念之一就是所有工作产品都具有明确的和可测量的规格说明，我们可以将每个过程的产品 与这一规格说明进行比较。反馈循环对于减少产生的缺陷是至关重要的。 2、质量成本的构成有哪些？
质量成本包括所有由质量工作或者进行与质量有关的活动所引发的成本。
质量成本可以细分为与预防成本、鉴定成本 及失效成本。 ? 预防成本包括质量计划、正式技术复审、测试设备及培训。
? 鉴定成本包括为深入了解“首次通过”各个过程时的产品状态而开展的那些活动。如：过程内和过程间的审查，设备校准和维护，测试。
? 失效成本是指如果将产品交付给客户之前没有缺陷的话就不会存在的成本。 3、如何定义软件质量？
软件要符合明确的功能和性能需求，符合已清晰文档化的开发标准，并且具有专业人员开发的软件所应有的隐含特征。 定义强调了以下三个重要方面：
1) 软件需求是进行质量测量的基础。与需求不符就是质量不高。
2) 规定的标准定义了一组指导软件开发的准则。如果不能遵照这些准则，就极
有可能导致质量不高。
3) 通常有一组“隐含需求”是不会被明确提出的（如对易用性和易维护性的需
求）。如果软件明确提出的需求，却没有满足隐含需求，软件质量仍然值得怀疑。
4、SQA小组的作用是什么？
SQA小组的职责是辅助软件团队实现高质量的软件产品。 SQA活动都是由一个独立的SQA小组完成的，包括以下的工作： 1) 编制项目质量保证计划 2) 参与项目的软件过程描述的编写
3) 评审软件工程活动，以验证是否符合规定的软件过程
4) 审核指定的软件工作产品以验证是否遵守作为软件过程一部分的那些规定 5) 确保根据文档化的规程记录和处理软件工作及工作产品中的偏差 6) 记录各种不符合的部分，并报告给高层管理人员 5、我们什么时候进行FTR，我们的目标是什么？ FTR的目标是：
(1)发现软件的任何一种表示形式中的功能、逻辑或实现上的错误； (2)验证评审中的软件是否满足其需求； (3)保证软件的表示符合预先定义的标准；
(4)得到以统一的方式开发的软件； (5)使项目更易于管理。
FTR一般从介绍会议日程并由生产者做简单的介绍开始。然后由生产者“走查”该工作产品，并对材料做出解释，而评审者则根据预先的准备提出问题。当发现了有根据的问题或错误时，记录员逐一加以记录。
6、假设需求模型引入了10个错误，每个错误按2：1的比例在设计阶段放大，设计阶段引入了另外的20个错误，并且这20个错误按1.5：1的比例在编码阶段放大，在编码阶段又引入了另外30个错误。进一步假设，所有单元测试会发现所有错误的30%，集成测试将找到剩余错误的30%，验证测试会发现剩余错误的50%。没有进行评审，有多少错误将被发布到现场？ 10×2＝20 20×1.5＋20＋30＝80 80×﹙1－30％﹚＝56 56×﹙1－30％﹚＝39 39×﹙1－30％﹚＝20
7、重新考虑第6题所述情形，但现在进行了需求评审、设计评审和代码评审，并且这些步骤能有效地发现所有错误的60%。有多少错误将被发布到现场？ 10×0.4＝4
﹙4×2＋20﹚×0.4＝11 ﹙11×1.5＋30﹚×0.4＝19 19×0.7＝13 13×0.7＝9 9×0.5＝5
8、重新考虑第6题和第7题所述情形，对于每个发布到现场的错误，发现和改正的成本是4800美元，在评审时发现并改正每个错误花费240美元，通过进行评审节约多少钱？
评审阶段发现并改正的错误：
10×0.6＋﹙4×2＋20﹚×0.6＋﹙11×1.5＋30﹚×0.6＝51