风险计划与跟踪表模版【荐】.xlsVIP

风险分类指南 图表显示 风险汇总 风险跟踪列表 effort.ta size.ta Issue 需求 设计 编码和单元测试 集成和测试 验收和维护 团队 成本 组织和管理 ID 状态 描述 识别时间 可能性 影响 程度 优先级 避免/减缓计划 应急计划 数值 等级 时间 人员 内容 负责人 执行情况 触发条件 需求 设计 风险图示 风 险 测 量 风险类别（分布） 验收和维护 团队 编码和单元测试 成本 集成和测试 风险状态（数目） 风险优先级（分布） ISSUE ACTIVE 中 ≥ 0.8 ＜ 1.5 CLOSE 低 ＜ 0.8 风险总量（数目） 提交人 提交日期 风险状态 高 中 低 合计 Issued Active Closed Close Active 可能造成的危害 项目风险分类 1. 需求 需求没有文档化 [1] 是否仅有未成文的需求？ 如果项目的需求只是通过口头表达，则需要考虑风险。 需求不稳定 [2] 需求是否正在变化或是已经确定下来了？ 如果需求正在被增加、变更或是没有被确定下来，则需要考虑风险。 需求不完全 [3] 需求中所有项目是否都有详细说明？ 如果需求中有未列出详细说明的项目，则需要考虑风险。 需求可读性差 [4] 需求文档的可读性如何？ 如果需求文档的可读性差，则需要考虑风险。 需求不清晰 [5] 你是否可以理解需求，如同作者想要表达的？ 如果关键的需求是模糊的、不明确的，则需要考虑风险。 需求进度紧张 [6] 进度中是否安排了足够的需求分析时间？ 如果需求分析阶段的进度紧张，则需要考虑风险。 需求分析能力有限 [7] 需求分析人员的能力是否有限？ 如果需求分析人员的能力有限，则需要考虑风险。 需求无经验可借鉴 [8] 项目需求的关键部分是否有以往的经验可以借鉴？ 如果需求的关键部分无法借鉴以往项目的经验，则需要考虑风险。 需求不可行 [9] 是否存在在实现时有技术困难的需求？ 如果不能确定某一项需求在所用的开发语言环境中实现的方法，则需要考虑风险。 需求不可跟踪 [10] 是否有计划在设计、编码和测试阶段对需求进行跟踪？ 如果需求与开发过程出现偏差，或是在各个阶段没有被把握住，则需要考虑风险 2. 设计 设计的算法有问题 [11] 是否存在没有满足需求或是仅仅部分满足需求的算法？ 如果算法有可能是错误的、不完整的，或是太复杂，则需要考虑风险。 设计难度大 [12] 是否存在难于设计的需求或是功能？ 在某些时候，如一个复杂的树的查询可能需要很多的精力来设计，则需要考虑风险。 设计难度偏大过偏小 [13] 设计中的任何一部分是否是基于不切实际的或是乐观的假设？ 如果对需求的设计太乐观或者太悲观，则需要考虑风险。 设计的接口定义不完全 [14] 是否内外部接口都已经很好的定义了？ 如果在系统内部或是系统间存在复杂的、大量的联系，则需要考虑风险 设计不易测试 [15] 软件是否易于测试？ 如果在测试产品时有很大的复杂性，则需要考虑风险。 设计有硬件约束 [16] 开发或是运行硬件是否对满足需求有限制？ 如果在硬件速度、容量、可用性和功能方面有限制，则需要考虑风险 设计有软件复用性要求 [17] 是否存在软件复用？ 需要考虑复用软件时的修改可能导致比设计新软件更多问题的风险。 3. 编码和单元测试 编码和单元测试的可行性 [18] 产品中是否有某些部分没有在设计说明书中被完全定义？ 如果没有在设计时跟踪需求就编码，则需要考虑风险。 [19] 设计说明书是否有足够的细节描述代码？ 如果设计处于太高的层次，则需要考虑风险。 编码进度偏差 [20] 是否存在充分的时间进行编码？ 如果在进度表中没有安排充分的时间进行编码，则需要考虑风险。 [21] 是否对项目组在编码时间和工作量方面的估计有意见？ 如果过于低估你的工作量，则需要考虑风险。 [22] 编码的实际进度是否与计划相比有比较大的偏差？ 如果编码的实际进度与计划相比有比较大的偏差，则需要考虑风险。 测试进度偏差 [23] 是否存在充分的时间进行全部的单元测试？ 如果在进度表中没有安排充分的时间进行测试，则需要考虑风险。 [24] 如果进度出现问题，是否会妥协，对单元测试进行调整？ 考虑谁将妥协，在什么模块，考虑什么可能被遗漏。 [25] 是否对项目组在编码时间和工作量方面的估计有意见？ [26] 测试的实际进度是否与计划相比有比较大的偏差？ 如果测试的实际进度与计划相比有比较大的偏差，则需要考虑风险。 编码工具问题 [27] 开发语言是否适合开发的软件产品？ 如果开发语言不适合开发的软件产品，则需要考虑风