一、需求

软件项目风险分类整理（软件项目风险分类整理方法）

二、设计

软件项目风险分类整理（软件项目风险分类整理方法）

三、编码和单元测试

软件项目风险分类整理（软件项目风险分类整理方法）

四、集成和测试

软件项目风险分类整理（软件项目风险分类整理方法）

五、验收和维护

软件项目风险分类整理（软件项目风险分类整理方法）

六、团队

软件项目风险分类整理（软件项目风险分类整理方法）

七、成本

软件项目风险分类整理（软件项目风险分类整理方法）

八、组织和管理

软件项目风险分类整理（软件项目风险分类整理方法）

原件：

项目风险分类

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] 是否有足够的硬件做充分的集成和测试工作？

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

集成和测试进度紧张

[31] 是否有足够的产品集成方面的说明，是否安排了充分的时间做集成工作？

需要考虑满足进度和足够测试覆盖率要求的风险。

5. 验收和维护

产品验收标准不一致

[32] 是否对全部需求的验收标准都已经达成一致？

如果不确切明了什么是用户所期望得到的，则需要考虑风险。

产品的可维护性不好

[33] 产品设计和相关文档是否可以充分满足另外一个组维护代码的要求？

如果产品设计和相关文档不能充分满足另外一个组维护代码的要求，则需要考虑风险。

6. 团队

员工经验不足

[34] 在项目组中是否有很多新员工？

如果新员工比较多，则需要考虑风险。

[35] 项目经理和开发组长的工作经验是否丰富？

如果项目经理或开发组长在以往没有相应的工作经验，则需要考虑风险。

员工流动性大

[36] 项目组成员在项目结束前是否有流动的可能性？

如果项目组成员在项目结束前有流动的可能性，则需要考虑风险。

内部缺乏交流

[37] 在项目组中是否缺乏方便的、有效的交流？

如果进度表与项目会议冲突，则需要考虑风险。

[38] 是否和上级缺乏有关项目的方便、有效的交流？

在缺乏完整的信息情况下，需要考虑工作产品的质量风险。

项目组内部合作缺乏氛围

[39] 项目是否以前合作过？

如果项目组不能很好的合作，或是以前没有很好合作的经历，则需要考虑风险。

[40] 项目组是否对任务有清楚的认识？

如果项目组内存在分歧，则需要考虑风险。

7. 成本

缺乏成本管理和跟踪

[41] 是否对成本有测量和跟踪？

如果没有对成本进行测量和跟踪，则需要考虑风险。

[42] 预算偏差

如果实际成本和预算有比较大的出入，则需要考虑风险。

8. 组织和管理

组织缺乏管理

[43] 组织是否有专门的人员负责管理？

如果组织没有人负责管理，则需要考虑风险。

决策者能力有限

[44] 管理层是否有威信，是否果断，决策人是否有很高的素质？

如果管理层没有威信，处理事务优柔寡断，素质不高，则需要考虑风险。

软件项目风险分类整理（软件项目风险分类整理方法）

一、需求

二、设计

三、编码和单元测试

四、集成和测试

五、验收和维护

六、团队

七、成本

八、组织和管理

相关推荐