风险项检查指南
1. 概述
软件风险伴随在项目的整个生命周期中，为了能把风险系统化的标识出来，在风险发生之前对其进行有效的预防、管理和控制，必须考虑不同类型的风险。
2. 风险类型
2.1 客户相关风险
• 是否曾与这个客户合作过
• 客户是否很清楚需要什么，能否花时间把需求写出来
• 客户是否同意召开正式的需求收集会
• 客户是否愿意建立与开发者的快速通信渠道
• 客户是否了解软件过程
• 客户是否愿意参加复审工作
• 该客户是否具有该产品领域的技术实力
• 该客户是否愿意让你的人来做他们的工作，即当你的人在做具体的技术工作时，该客户是否会坚持在旁边协助
如果对这些问题中的任何一个的答案是否定的，则需要进行进一步分析，以评估潜在的风险。
2.2 商业影响风险
• 本产品是否得到公司高级管理层的重视
• 交付期限合理性如何
• 最终用户的水平如何
• 本产品必须能与之互操作的其他产品/系统的数目
• 将使用本产品的用户数及本产品是否与用户的需要相符合
• 必须产生并交付给用户的产品文档的质与量如何
• 政府对本产品开发的约束
• 延迟交付所造成的成本消耗是多少
• 产品缺陷所造成的成本消耗是多少
对每一个问题的回答都必须与过去的经验加以比较，如出现了较大百分差或数字相近但过去的结果很不令人满意，则风险较高。
2.3 产品规模风险
• 是否以LOC或FP估算产品的规模
• 估算出来的产品规模的信任程度如何
• 产品规模与以前产品的规模平均值的偏差百分比是多少
• 产品创建或使用的数据库大小如何
• 产品的用户数有多少
• 产品需求改变多少，交付之前有多少，交付之后有多少
• 复用的软件有多少
2.4 过程风险
• 开发人员是否同意按照文档所写的软件过程进行开发工作，并自愿使用它
• 是否定期对需求规约、设计和编码进行正式技术复审
• 是否定期对测试过程和测试情况进行复审
• 是否对每一次的正式技术复审的结果建立了文档，其中包括发现的错误和使用的资源
• 是否使用配置管理来维护系统/软件需求、设计、编码和测试用例之间的一致性
• 是否使用一个机制来控制用户需求的变化及其对软件的影响
• 对于每一个承包出去的子合同，是否有一份文档化的工作说明，一份软件需求规约及一份软件开发计划
• 是否有一个可遵循的规程，来跟踪及复审子合同承包商的工作
2.5 技术风险
• 该技术对于你的组织而言是否是新的
• 客户的需求是否需要创建新的算法或输入、输出技术
• 软件是否需要使用新的或未经证实的硬件接口
• 待开发的软件是否需要与开发商提供的未经证实的软件接口
• 产品需求中是否要求采用特定的用户界面
• 待开发的软件是否需要与其功能及性能均未在本领域中得到证实的数据库接口
• 需求中是否要求使用新的分析、设计、测试方法
• 需求中是否有过分的对产品的性能约束
• 客户能确定所要求的功能是“可行的”
2.6 与人员数目及经验相关的风险
• 是否有最优秀的人员可用
• 人员在技术上是否配套
• 是否有足够的人员可用
• 开发人员是否能够自始至终的参加整个项目的工作
• 项目中是否有一些人员只能部分时间工作
• 开发人员对自己的工作是否有正确的期望
• 开发人员是否接受过必要的培训
• 开发人员的流动是否仍能保证工作

风险项检查指南