风险与管理计划及跟踪表.pdfVIP

风险与管理计划及跟踪表

项目风险分类

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]开发语言是否适合开发的软件产品？

如果开发语言不适合开发的软件产品，则需要考虑风险。

[28]项目组是否在开发语言、开发平台或是开发工具方面有足够的经验？

如果项目组在开发语言、开发平台或是开发工具方面没有良好的开发经历，则需要考虑风

险。

编码缺乏配置管理

[29]是否有代码的配置管理计划？

如果没有版本控制或是代码修改不受控，则需要考虑风险。

4.集成和测试

集成和测试硬件支持不足

[30]是否有足够的硬件做充分的集成和测试工作？

如果没有足够的硬件资源，则需要考虑风险。

集成和测试进度紧张

[3