常见软件项目风险检查表学习资料

项目风险检查表

项目风险检查表
商业风险
风险源
检查项
法律
市场
政府或其他机构对本项目的开发是否有限制
是否有不可预测的市场动荡
竞争对手是否有不正当的竞争行为
是否有不利于我方的官司要打
是否在开发市场前景把握不定的产品
是否在开发可能亏本的产品
客户
客户的需求是否含糊不清
客户是否反复的改动需求
客户指定的需求和交付期限在客观上是否可行
需求开发人员是否与客户对有争议的需求达成共识
技术能力
本项目是否为新行业、新领域
本项目是否包含有新技术
本项目是否需要创建新的算法或输入、输出技术
本项目是否要求采用特定的用户界面
软件是否需要使用新的或未经证实的硬件接口
是否需要与开发商提供的未经证实软件产品接口
需求中是否要求使用新的分析、设计或测试方法
开发人员是否掌握了本项目的关键技术
客户对产品的健壮性可靠性、性能等质量因素是否有特殊要求
与客户签订的合同是否公正、是否双方互利
客户是否有良好的信誉
客户领导是否重视不足
客户是否合作难度大
客户基础是否太差
子承包商
供应商
签订产品
是否有能力做好售后服务
是否可能倒闭
是否有良好的信誉
管理风险
风险源
开发人员是否有开发类似产品的经验
是否选择了合适的分析、设计、编程和测试工具
开发环境
是否有可用的项目管理工具
是否有可用的软件过程管理工具
是否有可用的分析及设计工具，是否适用于待建造产品
是否有可用的编译器或代码生成器，且适用于待建造产品
是否有可用的测试工具，且适用于待建造产品
是否有可用的软件配置管理工具

项目确立时的风险及可行性检查表

称：顾客零部件号：风险评价：0=无风险1=小风险2=中风风险点数总计不超过5，且不存在小风险以上的风险时，可行性评审通过。

日期：编号:表号:合同类型：项目：厂内为料号：称：顾客零部件号：风险评价：0=无风险1=小风险2=中风风险点数总计不超过5，且不存在小风险以上的风险时，可行性评审通过。

日期：编号:表号:合同类型：项目：厂内为料号：D环境检查称：顾客零部件号：风险评价：0=无风险1=小风险2=中风风险点数总计不超过5，且不存在小风险以上的风险时，可行性评审通过。

日期：编号:表号:合同类型：项目：厂内为料号：称：顾客零部件号：风险评价：0=无风险1=小风险2=中风风险点数总计不超过5，且不存在小风险以上的风险时，可行性评审通过。

软件项目风险评估表

风险评估表编号 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 4 4.1 4.2 评估项系统规模与功能系统开发的总工作量项目持续时间项目内的子项目数量项目所涉及的客户部门数量安装完成以后的最终用户数（含系统管理用户）系统部署涉及的地理位置数量与本系统有接口的外部系统数量系统的技术复杂性客户特点和系统需求对系统最适当的描述是开发小组对需求的理解程度系统的实时性能要求总分 28 5 4 3 3 3 3 3 4 27 2 4 3 评分风险比 20 4 4 1 1 3 2 3 2 13 2 2 3 1 1 2 1 1 0 0 2 0 0 1 0 0 1 0 7 2 2 30% 4.3 4.4 4.5 项目规划是否被正式批准，且跟踪记录和工作报告被记录在案 4 具有项目所需技能的人员是否到位主要体系结构或关键技术是否有书面记录并且被正式批准 5 3 要调整客户的组织结构或过程才能满足新系统的要求 2 开发小组在修改客户需求时有多大程度的灵活性和决策能力 3 客户在修改需求时有多大程度的灵活性和决策能力该项目是否依赖于另一个项目的输出和产品客户的普遍态度如何客户管理层对项目的热衷程度如何客户方在项目中的参与程度如何技术与外部相关性开发中是否熟悉所需的硬件是否需要特殊的非标准硬件系统中所使用的软件有多少需要重新开发开发者对产品的熟悉程度如何所采用的开发方法与系统的新颖性如何硬件供应商/软件供应商/工具供应商的支持程度如何开发小组对应用领域的了解程度如何项目管理与特征项目进度安排、主要的阶段成果和操作日期由项目经理是否已经确定？经验和培训情况如何 4 3 2 2 2 22 3 2 4 3 4 3 3 23 4 7

【最新精选】常见软件项目风险检查表

软件项目风险检查表修改记录页目录1.引言 (3)1.1目的 (3)1.2适用范围 (3)1.3角色与职责 (3)2.风险检查参考列表 (3)1. 引言1.1 目的风险检查表的目的是提供风险检查参考列表，在实施项目的过程中，根据本表生成该项目的风险管理卡，识别该项目潜在的风险，以便策划应对风险的活动和在整个项目生存周期中实施这些活动，缓解并消除潜在的风险。

1.2 适用范围本文档作为项目风险识别的初始依据和指导，使用者根据本机构和项目的实际情况不断地完善本表内容。

1.3 角色与职责2. 风险检查参考列表【附加总结类文档一篇，不需要的朋友可以下载后编辑删除，谢谢】2015年文化馆个人工作总结在XXXX年X月，本人从XXXX学院毕业，来到了实现我梦想的舞台--XX区文化馆工作。

在这里我用艰辛的努力，勤劳的付出，真诚而认真地工作态度认真的做好自身的每一项文化馆相关工作，取得了较为良好的工作业绩。

随着一场场活动的成功举办、一台台戏剧的成功出演，在这个带有着梦想和希望的舞台上，转眼之间我已在这里渡过了XX年的青春事业，我亦与舞台共同成长，逐步由一名青涩的毕业生，历练成为了今天的XXX。

梦想在于不断坚持，未来的旅途在于不断的前进，在这个承载着梦的舞台上，我持以坚定的信心和丰富的工作能力与工作经验，一步一步超前迈进着。

下面我将自身XX年来的工作能力情况总结如下：一、一专多能服务1、高端学识水平。

本人于XXXX年XX月毕业于XXXX大学XX专业。

随后于XXXX年X 月进入XX区文化馆从事XX工作，至今已有XX年的时间。

在本人从事文化馆XX工作的XX年里，我始终坚持积极探索、勤奋学习，做到辅助教学与实际工作相长，坚定与时俱进的思想理念，努力攻克各项困难，将提高效益型，能力型的工作绩效作为自己的奋斗目标，并在自身的素质方面进行了坚持不懈的强化与提高。

我深知，要不断充实自身能力，深化提升自身素质，才能够不断更新自我，超越自我，为我XX区文化馆的发展与活动做出奉献。

项目风险检查表及评估报告

项目所需的软件、硬件能按时到位吗？
项目的经费够用吗？
进度安排是否过于紧张？有合理的缓冲时间吗？
进度表中是否遗忘了一些重要的（必要的）任务？
进度安排是否考虑了关键路径？
是否可能出现某一项工作延误导致其它一连串的工作也被延误？
任务分配是否合理？（即把任务分配给合适的项目成员，充分发挥其才能）
是否为了节省钱，不采用（购买）成熟的软件模块，一切从零做起？
子承包商
供应商
与子承包商、供应商签订的合同公正吗？双方互利吗？
子承包商、供应商的信誉好吗？
子承包商、供应商有可能倒闭吗？
子承包商、供应商能及时交付质量合格的产品（或部件）吗？
子承包商、供应商有能力做好售后服务吗？
管理风险
风险类型
检查项
项目计划
对项目的规模、难度估计是否比较正确？
人力资源（开发人员、管理人员）够用吗？合格吗？
…
项目团队
项目成员团结吗？是否存在矛盾？
是否绝大部分的项目成员对工作认真负责？
绝大部分的项目成员有工作热情吗？
团队之中有“害群之马”吗？
技术开发队伍中有临时工吗？
本项目开发过程中是否会有核心人员辞职、调动？
是否能保证“人员流动基本不会影响工作的连续性”？
项目经理是否忙于行政事务而无暇顾及项目的开发工作？
机构是否有较好的奖励和惩罚措施？
本项目的合作部门的态度积极吗？是否应付了事？或者做事与承诺的不一致？
技术风险
风险类型
检查项
需求开发
需求管理
需求开发人员懂得如何获取用户需求吗？效率高吗？
需求开发人员懂得项目所涉及的具体业务吗？能否理解用户的需求？
需求文档能够正确地、完备地表达用户需求吗？

项目风险检查表完整版

风险可能性等级
参数
等级
值
描述
风险
可能性
很高
5
风险发生的几率为～
比较高
4
风险发生的几率为～
中等
3
风险发生的几率为～
比较低
2
风险发生的几率为～
很低
1
风险发生的几率为～
风险系数等级
风险
系数
风险可能性
很高5
比较高4
中等3
比较低2
很低1
风险
严重性
很高5
25
20
15
10
5
较高4
20
16
12
8
4
中等3
15
12
项目风险检查表
风险严重性等级
参数
等级
值
描述
风险
严重性
很高
5
例如进度延误大于30％，或者费用超支大于30％
比较高
4
例如进度延误20%－30％，或者费用超支20%－30％
中等
3
例如进度延误低于20％，或者费用超支低于20％
比较低
2
例如进度延误低于10％，或者费用超支低于10％
很低
1
例如进度延误低于5％，或者费用超支低于5％
需求文档能够正确地、完备地表达用户需求吗？
需求开发人员能否与客户对有争议的需求达成共识？
需求开发人员能否获得客户对需求文档的承诺？以保证客户不随便变更需求？
综合技术
开发能力
包括设计
编程、测试等
开发人员是否有开发相似产品的经验？
待开发的产品是否要与未曾证实的软硬件相连接？
对开发人员而言，本项目的技术难度高吗？

软件项目风险检查表模板

1）了解旧系统的功能，继承旧系统的优点，并提供用户需求但旧系统又无法满足的功能或质量；2）提供数据迁移功能。
严重
0
1.4
需要用户提供的资料、设备、工具不能及时提供
1）在项目计划中明确用户要提供的交付物及其交付时间，并与客户及时沟通；
严重
0
2）从其他项目借鉴相关资料等或者构建模拟的用户环境。
2
公司内部风险
1）加强QA和配置管理的力度；2）加强阶段交付物的评审。
一般
0
2.4
绝大多数项目组成员之间以前没有合作过
1）进行适当的管理培训和经验交流学习；2）组织相关的业余活动。
一般
0
2.5
可能选择了错误的技术方案或者供应商
1）应用正式的DAR决策过程，并参考以前的决策经验；2）选择一个备选方案；3）进行快速验证。
一般
0
2.6
组织内其他部门和项目组的不能提供积极的配合
制定合作制度，定期与部门进行沟通。
一般
0
2.7
项目是在已有的软件或产品的基础上进行相关应用开发，可能由于原有代码的质量问题或对原业务不了解，影响本项目的开发进度
适当的安排对原有模块学习时间。
一般
0
2.8
项目组成员由于还参与了别的项目的工作，无法保证参与本项目的时间，影响本项目的开发进度
1）通过客户向合作厂家发出邀请或索要资料；2）寻找替代选择方案。
一般
0
软件
编号
风险检查项
建议应对措施
影响程度
出现次数
1
客户相关风险
1.1
项目需求不是客户或用户直接提出的
寻找合适的客户、用户或业务专家在适当的时机进行确认
严重

项目风险表(新版)

项目风险表(新版)1. 引言本文档旨在识别和评估当前项目的各类风险，以便及时采取相应的措施进行预防和应对，确保项目的顺利实施和成功完成。

2. 风险识别在项目实施过程中，可能面临以下风险：2.1 技术风险- 技术选型不合理导致实施难度增加- 技术人员能力不足影响项目进展- 系统可靠性和稳定性问题2.2 资源风险- 项目所需资源供应不足- 预算不足导致项目进展受限- 项目所需人力资源的流失和不稳定性2.3 时间风险- 进度延误导致项目交付延迟- 项目开发周期过长导致后续环节受影响- 项目中的关键节点无法按时完成2.4 运营风险- 用户需求变化导致产品功能不匹配- 竞争对手的产品在市场上占有优势- 相关政策法规的变化对项目实施产生影响3. 风险评估为了评估风险的严重程度和影响程度，将采用以下等级进行评估：- 高风险：可能导致项目无法顺利完成，且对组织产生重大影响- 中风险：可能导致项目进展受限，且对组织产生一定影响- 低风险：对项目进展和组织影响较小，但仍需要关注4. 风险应对措施针对各类风险，制定相应的应对措施将有助于降低风险发生的概率和严重程度。

具体的应对措施如下：- 技术风险：加强技术人员培训和沟通交流，对技术选型进行评估和优化。

- 资源风险：及时预测和计划所需资源，合理控制成本并保障人力资源的稳定性。

- 时间风险：合理制定项目进度计划，加强项目管理和团队协作。

- 运营风险：不断关注市场变化和竞争动态，持续优化产品功能和服务。

5. 总结项目风险表(新版)旨在为项目开展提供风险识别和应对的参考，通过合理评估和有效控制风险，有助于保证项目的顺利进行和成功完成。

对于项目组的相关人员来说，需要认真对待风险，并积极采取措施以应对和化解潜在的风险。

防病毒防恶意软件安全检查表

防病毒防恶意软件安全检查表介绍本文档为防病毒和防恶意软件安全检查表，用于确保计算机系统和网络的安全。

通过定期检查以下项目，可以有效减少病毒和恶意软件对系统的威胁。

安全检查项目1. 病毒防护软件- 检查计算机系统是否安装了最新版本的病毒防护软件。

- 确保病毒防护软件的病毒数据库处于最新状态。

- 验证病毒防护软件是否启用了实时保护功能。

2. 恶意软件防范- 检查计算机系统是否安装了恶意软件防范工具。

- 确保恶意软件防范工具的恶意软件数据库处于最新状态。

- 验证恶意软件防范工具是否启用了实时检测功能。

3. 系统安全更新- 确认操作系统是否安装了最新的安全更新补丁。

- 检查应用程序及浏览器是否安装了最新的安全更新。

4. 邮件和文件下载安全- 教育员工要警惕电子邮件附件中的潜在风险，特别是来自不明来源的邮件。

- 建议员工只从可信任的网站下载文件，避免下载未知来源的文件。

5. 强密码和账户安全- 强调员工使用强密码，并定期更改密码。

- 确保员工账户没有共享密码，避免使用相同密码多次。

6. 网络防火墙- 确保网络防火墙已正确配置，阻止未经授权的访问。

- 定期检查网络防火墙的日志，以便发现异常活动并采取相应措施。

7. 员工培训和意识- 提供有关病毒和恶意软件的培训，以加强员工对安全威胁的认识。

- 教育员工如何识别和应对可能存在的安全风险。

结束语执行本检查表的内容将有助于保护计算机系统和网络免受病毒和恶意软件的侵害。

建议定期复查和更新检查表，以适应不断变化的安全威胁。

风险对照检查表

机构是否有较好的奖励和惩罚措施？
本项目的合作部门的态度积极吗？是否应付了事？或者做事与承诺的不一致？
技术风险
风险类型
检查项
评分（1~5）
需求开发
需求管理
需求开发人员懂得如何获取用户需求吗？效率高吗？
需求开发人员懂得项目所涉及的具体业务吗？能否理解用户的需求？
需求文档能够正确地、完备地表达用户需求吗？
需求开发人员能否与客户对有争议的需求达成共识？
需求开发人员能否获得客户对需求文档的承诺？以保证客户不随便变更需求？
综合技术
开发能力
包括设计
编程、测试等
开发人员是否有开发相似产品的经验？
待开发的产品是否要与未曾证实的软硬件相连接？
对开发人员而言，本项目的技术难度高吗？
开发人员是否已经掌握了本项目的关键技术？
子承包商
供应商
与子承包商、供应商签订的合同公正吗？双方互利吗？
子承包商、供应商的信誉好吗？
子承包商、供应商有可能倒闭吗？
子承包商、供应商能及时交付质量合格的产品（或部件）吗？
子承包商、供应商有能力做好售后服务吗？
管理风险
风险类型
检查项
评分（1~5）
项目计划
对项目的规模、难度估计是否比较正确？
人力资源（发人员、管理人员）够用吗？合格吗？
项目所需的软件、硬件能按时到位吗？
项目的经费够用吗？
进度安排是否过于紧张？有合理的缓冲时间吗？
进度表中是否遗忘了一些重要的（必要的）任务？
进度安排是否考虑了关键路径？
是否可能出现某一项工作延误导致其它一连串的工作也被延误？
任务分配是否合理？（即把任务分配给合适的项目成员，充分发挥其才能）
是否为了节省钱，不采用（购买）成熟的软件模块，一切从零做起？

软件开发典型风险检查清单

1
计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致
2
计划是优化的，是“最佳状态”，但计划不现实，只能算是“期望状态”
3
计划基于使用特定的小组成员，而那个特定的小组成员其实指望不上
4
产品规模（代码行数、功能点、与前一产品规模的百分比）比估计的要大
5
完成目标日期提前，但没有相应地调整产品范围或可用资源
6
涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多
组织和管理风险
1
由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长
2
低效的项目组结构降低生产率
3
管理层审查决策的周期比预期时间长
4
预算削减，打乱项目计划
5
管理层作出了打击项目组织积极性的决定
6
缺乏必要的规范，导致工作失误与重复工作
软件开发典型风险检查清单收藏软件开发典型风险检查清单编号风险列表缺少有效的需求变化管理过程计划编制风险计划资源和产品定义全凭客户或上层领导口头指令并且不完全一致计划是优化的是最佳状态但计划不现实只能算是期望状态计划基于使用特定的小组成员而那个特定的小组成员其实指望不上完成目标日期提前但没有相应地调整产品范围或可用资源涉足不熟悉的产品领域花费在设计和实现上的时间比预期的要多组织和管理风险由管理层或市场人员进行技术决策导致计划进度缓慢计划时间延长非技术的第三方的工作预算批准设备采购批准法律方面的审查安全保证等时间比预期延长人员风险开发人员和管理层之间关系不佳导致决策缓慢影响全局某些人员需要更多的时间适应还不熟悉的软件工具和环境项目后期加入新的开发人员需进行培训并逐渐与现有成员沟通从而使现有成员的工作效率降低由于项目组成员之间发生冲突导致沟通不畅设计欠佳接口出现错误和额外的重复工作不适应工作的成员没有调离项目组影响了项目组其他成员的积极性没有找到项目急需的特定技能的人开发环境风险开发工具不如期望的那样有效开发人员需要时间创建工作环境或者切换新的工具新的开发工具的学习期比预期的长内容繁多客户风险客户的意见未被采纳造成产品最终无法满足客户要求因而必须重做客户没有或不能参与规划原型和规格阶段的审核导致需求不稳定和产品生产周期的变更客户答复的时间如回答或澄清与需求相关问题的时间比预期长客户提供的组件质量欠佳导致额外的测试设计和集成工作以及额外的客户关系管理工作产品风险矫正质量低下的不可接受的产品需要比预期更多的测试设计和实现工作严格要求与现有系统兼容需要进行比预期更多的测试设计和实现工作要求与其他系统或不受本项目组控制的系统相连导致无法预料的设计实现和测试工作在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题依赖正在开发中的技术将延长计划进度设计和实现风险一些必要的功能无法使用现有的代码和库实现开发人员必须使用新的库或者自行开发新的功能代码和库质量低下导致需要进行额外的测试修正错误或重新制作分别开发的模块无法有效集成需要重新设计或制作过程风险太不正规缺乏对软件开发策略和标准的遵循导致沟通不足质量欠佳甚至需重新开发过于正规教条地坚持软件开发策略和标准导致过多耗时于无用的工作

软件项目风险管理(风险识别、预测、评估、缓解、监控)

软件项目风险管理一、风险管理概述软件风险是指软件开发过程中及软件产品本身可能造成的伤害或损失。

风险关注未来的事情，这意味着，风险涉及选择及选择本身包含的不确定性，在软件开发过程及软件产品都要面临各种决策的选择。

风险是介于确定性和不确定性之间的状态，是处于无知和完整知识之间的状态。

另一方面，风险将涉及思想、观念、行为、地点等因素的改变。

当在软件工程领域考虑风险时，我们要关注以下的问题：什么样的风险会导致软件项目的彻底失败？用户需求、开发技术、目标计算机、以及所有其它与项目有关的因素的改变将会对按时交付和总体成功产生什么影响？对于采用什么方法和工具，需要多少人员参与工作的问题，我们如何选择和决策？对软件质量要达到什么程度才是“足够的”？当没有办法消除风险，甚至连试图降低该风险也存在疑问时，这些风险就是真正的风险了。

在我们能够标识出软件项目中的真正风险之前，识别出所有对管理者和开发者而言均为明显得风险是很重要的。

二、被动和主动的风险策略被动风险策略是针对可能发生的风险来监督项目，直到它们变成真正的问题时，才会拨出资源来处理它们，更普遍的是，软件项目组对风险不闻不问，直到发生了错误才赶紧采取行动，试图迅速地纠正错误。

这种管理模式常常被称为“救火模式”。

当补救的努力失败后，项目就处在真正的危机之中了。

对于风险管理的一个更聪明的策略是主动式的。

主动策略早在技术工作开始之前就已经启动了――标识出潜在地风险，评估它们出现的概率及产生的影响，对风险按重要性进行排序，然后，软件项目组建立一个计划来管理风险。

主动策略风险管理的主要目标是预防风险。

但是，因为不是所有的风险都能够预防，所以，项目组必须建立一个应付意外事件的计划，使其在必要时能够以可控的及有效的方式作出反应。

三、软件风险1、软件风险包含两个特征：不确定性——刻划风险的事件可能发生也可能不发生，没有100％发生的风险。

损失——如果风险变成了现实，就会产生恶性后果或损失。

【VIP专享】常见软件项目风险检查表

软件项目风险检查表修改记录页NO修改日期修改摘要（涉及页码/条款/内容）版本修改原因目录1.引言 (3)1.1目的 (3)1.2适用范围 (3)1.3角色与职责 (3)2.风险检查参考列表 (3)1.引言1.1目的风险检查表的目的是提供风险检查参考列表，在实施项目的过程中，根据本表生成该项目的风险管理卡，识别该项目潜在的风险，以便策划应对风险的活动和在整个项目生存周期中实施这些活动，缓解并消除潜在的风险。

1.2适用范围本文档作为项目风险识别的初始依据和指导，使用者根据本机构和项目的实际情况不断地完善本表内容。

1.3角色与职责2.风险检查参考列表商业风险风险类型风险来源1政府或者其它机构是否对本项目的开发有限制？政治/法律2项目中间有没有产品存在版权纠纷？3项目会不会对个人隐私造成干扰？4项目是否使用了非法数据？5项目是否产生了非法数据？6投标商是否可能采用了非法的竞争手段？1客户合作态度是否友善？客户2客户在项目上是否有准备出足够的时间？3客户的人员数目是否足够？4客户的业务是否足够熟练并胜任本项目？5客户的各领导层是否支持本项目？6客户部门内或者外是否有人对项目持否定态度？7客户的历史合作信誉度如何？8客户是否易反复而不信守承诺？9客户是否对项目有不符实际的较高要求？10软件最后用户数量大大超过最初设计数量？1与承包商/供应商签订的合同公正吗？互利吗？承包商/供应商2承包商/供应商的信誉好吗？3承包商/供应商是否容易倒闭？4承包商/供应商的售后服务有保证吗？5承包商/供应商的人员队伍稳定吗？6承包商/供应商的历史项目是否非常成功？7承包商/供应商的人员结构是否合理？8承包商/供应商能提供给本项目的合适的人员吗？9承包商/供应商是否为了应对本项目而临时招聘人员？10承包商/供应商是否可能撤出本项目的市场而转型？11承包商/供应商是否为了拿到项目而故意降低报价？12承包商/供应商的报价是否已经离我方估算偏差较大？13承包商/供应商是否有追加变更而赚取利润的企图？项目风险风险类型风险来源1项目组是否能够准确把握项目规模？项目计划2项目组是否真正地理解了客户需求？3是否根据需求进行了估算，估算方法是否合理？4估算的成本是否高于预算经费却不能得到足够经费？5是否需要采购软硬件开发设备？能否及时到位？6人力资源的配置能够满足项目的需要吗？7进度计划安排是否过于紧张？8有没有合理的项目缓冲时间？9进度计划表是否覆盖所有研发任务？10任务的分配能够充分发挥团队成员的积极能动性吗？11是否明确项目进度阶段里程碑？1是否有人对项目或者技术产生抵触，并进行破坏？沟通理解2SQA人员是否积极按照制度参与项目的QA工作？3项目成员是否团结？工作氛围是否活跃？4成员表达沟通能力是否让管理层满意？5是否制定奖赏惩罚措施？奖赏惩罚措施是否严格执行？6临时成员是否占项目成员的较大比率？7人员变动包括核心人员吗？8项目成员是否明确自己的职责？9项目经理或者调研人员能够及时与客户进行沟通吗？10沟通的氛围是否友好？沟通的效率高不高？11项目的成员有相关工作的经验吗？12客户的表达能力是否强？13我方的理解能力是否强？14客户是否理解我方对客户需求的分析说明？15项目组人员是否懂得项目相关的具体业务知识？16具体业务有没有行业规范参考？17需求文档能够正确表达客户的需求吗？18需求文档对开发人员阅读有困难吗？19需求有没有存在争议？20项目资源的分配会不会随时被抽调到别的项目？21本项目的合作部门的态度是否积极？22项目组人员是否能够严格遵守项目管理制度？技术风险风险类型风险来源1开发人员是否有开发相似产品的经验？人力资源2核心人员对技术的熟悉程度是不是达到要求？3项目研发的核心技术是不是为开发人员所掌握？4若技术从来没有接触过，开发人员是否有足够的学习能力？5项目中是否有一些人员只能部分时间工作6开发人员是否接受过必要的培训?7项目开发人员是否配套？1开发小组是否采用比较有效的分析、设计、编程、测试工具？质量控制2分析与设计工作是否过于简单、草率，从而让程序员边做边改？3开发人员对测试工作重视吗？4项目有独立的测试人员吗？5测试人员掌握了相关测试工具和方法了吗？6是否对重要的工作成果进行同行评审？7开发人员有没有进行版本控制？8管理人员有没有进行变更控制措施和制度措施保证？9配置人员能够按照配置管理规范执行吗？10是否会在进度延误时降低质量要求？11项目成员是否按照度量规范记录相关内容?1待开发的产品是否要与其它软件有接口？开发环境2待开发的产品是否要应用未曾接触的开发架构？3待开发的产品是否要使用未曾接触的开发工具？4待开发的产品是否要使用未曾使用过的开发技术？5待开发的产品是否要部署在未曾接触的硬件环境？6设计工具存在多样选择吗？设计工具统一吗？7设计文档样式有明确规定吗？8开发小组采用统一的编程规范吗？9由于功能复杂，导致项目编程语言种类繁多吗？10维护工作有没有采用专门工具进行跟踪管理？11因为维护产生的代码修改有没有及时纳入版本控制？12维护范围、进度、人员、规范的定义是否明确？开发阶段风险风险类型风险来源1用户的需求是否合理？需求阶段2需求文档是否整理出use case?3用户是否对确认的需求做出承诺？4项目成员是否能够根据需求整理出用户使用文档？5用户需求是否有不断膨胀、不断变化的危险？6是否有工作量估算错误导致进度安排错误的危险?7需求中是否有过分的对产品的性能约束?8对重要复杂的需求有开发的界面原形来解释吗？9对需求规格说明书，用户有正式文档确认吗？10对后续阶段中需求变更的管理是否能够按照规范执行？11待开发的软件是否需要使用新的或未经证实的硬件接口？1概要设计文档是否合理？是否敷衍了事？设计阶段2详细设计文档是否合理？是否敷衍了事？3有架构设计文档吗？有框架设计代码吗？有示例吗？4设计阶段采用的设计工具合适吗？符合项目的要求吗？5设计阶段成果做了同行评审了吗？6对同行评审的结果认真贯彻执行了吗？7相应的工具如报表系统适合本系统吗？1是否能够按照配置管理规范进行开发？代码开发2是否能够遵守项目代码开发规范？3项目组是否认真解决周例会发现的问题？4项目组能够经常做代码复用和整合的工作吗？1是否认真执行各种测试规范？测试2是否使用了自动测试工具？3测试人员是否合格？4用户参与测试是否积极？参与力度是否足够？SCM1配置管理人员是否有足够的知识技能？2代码和文档的备份能够达到每天1次，连续30天吗？3能够随时抽出以前的任一基线的代码版本吗？4开发人员掌握了配置管理工具的使用技能吗？1用户参与验收力度是否足够？验收2验收文档清单中的列表项是否都满足？3验收计划是否合理？1维护人员具有足够的维护知识技能吗？维护2维护人员是否足够？3维护阶段是否对维护过程记录了？。

软件产品开发风险检查方法

软件产品开发风险检查方法软件产品开发风险检查表（一）软件需求与风险管理（二）所谓风险是可能给项目的成功带来威胁或损失的情况。

这种情况还没有发生，也没有带来问题，而你希望它永远不会发生。

但这些潜在的问题可能会给项目成本费用、进度安排、技术方面、产品质量及团队工作效率等带来较大的负面影响。

而风险管理—一种软件工业的最佳方法—就是在风险给项目带来损失之前，就指明、评估并对风险加以控制。

如果不希望发生的事已经发生了，那就不再是风险，而是事实了。

只好通过项目事务( o n g o i n g )状态跟踪和校正过程来处理当前的问题。

风险管理分为:风险评价,风险避免,风险控制风险评价（risk assessment）是一个检查工程项目并识别潜在风险区域的过程。

可以通过列举通常的软件项目风险因素，如需求风险因素的办法来使风险识别（risk identification）更加方便容易。

本章后面描述了一些需求风险因素（Carr et al 1993；McConnell 1996）。

在风险分析中，应检查一些特定风险对目可能造成的潜在后果。

风险分级（risk prioritization）有助你通过评价每项风险的潜在危害值，优先处理最严重的风险。

风险危害值(risk exposure)包括带来损失的可能性大小和潜在损失的规模。

风险避免（risk avoidance）是处理风险的一种方法：尽量别作冒险的事。

如果你不承担任何项目，采用成熟而并非处于研究阶段的技术，或者将难以实现的特性都排除在项目之外你就可以避开风险。

但更常见的是，需要采取风险控制（risk control）的方法来管理那些已被发现为高优先级的风险。

制定风险管理计划是一项处理具有一旦发生，影响较大的风险的计划，包括降低风险的方法、应急计划、负责人和截止日期。

应尽量避免让风险成为真正的问题，或即便问题发生了，也应尽量让其影响降低到最小。

风险不能够自我控制，所以风险解决方案就包括了降低、减少每项风险的执行计划。

风险识别检查表

如果对于这些问题中的任何一个的回答是肯定的，则需要进一步的调研，以评估潜在的风险。
如果对于这些问题中的任何一个的回答是肯定的，则需要进一步的调研，以评估潜在的风险。
a.a如果否，那么项目成员对项目状态报告是否没有反馈？ 03跟踪监 b是否没有向公司层面汇报合适的项目信息？控 c是否没有对照计划跟踪项目进展？ c.a如果否，那么管理是否没有一幅清晰的画面描述进展情况如何？ a项目成员是否没有活动在这个项目中所必需的技能培训？ a.a如果否，那么获得培训的安排是否没有计划？ b是否将经验与工作领域不匹配的人员分配到项目中？ c项目成员是否不容易管理？ 04人员管 d项目成员是否没有意识到项目计划里自己的职责？理 e项目成员是否觉得遵循计划不是很重要？ f在受影响的工作进行决策前，管理者是否与成员一起商议？ g与客户会见时，管理者是否安排合适的项目成员（如需求负责人、技术负责人、开发负责人、测试负责人等）？ a软件质量保证功能是否没有充分的在该项目中开展？ 05质 b是否没有定义质量保证的机制？量保证 b.a如果否，那么是否有些区域和阶段没有质量规程？ b.b如果否，项目成员工作时是否没有使用这些规程？ a是否没有适当的配置管理系统？ b配置管理功能是否提供的不充分？ 06配 c配置管理工具与需要安装在上面的系统是否不协调？置管 c.a如果否，那么配置管理系统是否与工作场所变更不同理步？ d配置管理工具是否安装在多个场所？ d.a如果是，那么配置管理系统是否没有提供给多个场所？ 07定 a在项目计划中是否没有制定定量管理的目标？量管 b数据分析时，所选的数据分析工具是否恰当？理 c项目是否采集不到合适的数据来供数据分析？ 09工作环境 a项目成员在职能边界处是否不合作？ 01合 b项目成员是否没有向共同目标有效的工作？作 c是否经常需要管理部门干涉来使大家一起工作？ a项目成员（如项目经理、技术负责人、开发人员、测试人员、配置管理人员、质量保证人员等）之间是否没有良好的沟通？ 02沟 b高级经理是否不善于与开发人员进行沟通？通 b.a如果否，那么你是否不能自由的向高级经理寻求帮助？ b.b如果否，那么项目成员是否不会及时向高层提出风险？ c项目成员是否不能及时获得影响他们工作的事件通知？ 03士气 a留住你所需的项目成员是否存在问题？如果对于这些问题中的任何一个的回答是肯定的，则需要进一步的调研，以评估潜在的风险。如果对于这些问题中的任何一个的回答是肯定的，则需要进一步的调研，以评估潜在的风险。