软件项目风险检查表
软件项目风险检查表
修改记录页
目录
1.引言 (3)
1.1目的 (3)
1.2适用范围 (3)
1.3角色与职责 (3)
2.风险检查参考列表 (3)
1. 引言
1.1 目的
风险检查表的目的是提供风险检查参考列表，在实施项目的过程中，根据本表生成该项目的风险管理卡，识别该项目潜在的风险，以便策划应对风险的活动和在整个项目生存周期中实施这些活动，缓解并消除潜在的风险。
1.2 适用范围
本文档作为项目风险识别的初始依据和指导，使用者根据本机构和项目的实际情况不断地完善本表内容。
1.3 角色与职责
2. 风险检查参考列表。
软件项目风险管理(风险识别、预测、评估、缓解、监控)
软件项目风险管理一、风险管理概述软件风险是指软件开发过程中及软件产品本身可能造成的伤害或损失。
风险关注未来的事情，这意味着，风险涉及选择及选择本身包含的不确定性，在软件开发过程及软件产品都要面临各种决策的选择。
风险是介于确定性和不确定性之间的状态，是处于无知和完整知识之间的状态。
另一方面，风险将涉及思想、观念、行为、地点等因素的改变。
当在软件工程领域考虑风险时，我们要关注以下的问题：什么样的风险会导致软件项目的彻底失败？用户需求、开发技术、目标计算机、以及所有其它与项目有关的因素的改变将会对按时交付和总体成功产生什么影响？对于采用什么方法和工具，需要多少人员参与工作的问题，我们如何选择和决策？对软件质量要达到什么程度才是“足够的”？当没有办法消除风险，甚至连试图降低该风险也存在疑问时，这些风险就是真正的风险了。
在我们能够标识出软件项目中的真正风险之前，识别出所有对管理者和开发者而言均为明显得风险是很重要的。
二、被动和主动的风险策略被动风险策略是针对可能发生的风险来监督项目，直到它们变成真正的问题时，才会拨出资源来处理它们，更普遍的是，软件项目组对风险不闻不问，直到发生了错误才赶紧采取行动，试图迅速地纠正错误。
这种管理模式常常被称为“救火模式”。
当补救的努力失败后，项目就处在真正的危机之中了。
对于风险管理的一个更聪明的策略是主动式的。
主动策略早在技术工作开始之前就已经启动了――标识出潜在地风险，评估它们出现的概率及产生的影响，对风险按重要性进行排序，然后，软件项目组建立一个计划来管理风险。
主动策略风险管理的主要目标是预防风险。
但是，因为不是所有的风险都能够预防，所以，项目组必须建立一个应付意外事件的计划，使其在必要时能够以可控的及有效的方式作出反应。
三、软件风险1、软件风险包含两个特征：不确定性——刻划风险的事件可能发生也可能不发生，没有100％发生的风险。
损失——如果风险变成了现实，就会产生恶性后果或损失。
项目 风险检查表及评估报告
项目的经费够用吗？
进度安排是否过于紧张？有合理的缓冲时间吗？
进度表中是否遗忘了一些重要的（必要的）任务？
进度安排是否考虑了关键路径？
是否可能出现某一项工作延误导致其它一连串的工作也被延误？
任务分配是否合理？（即把任务分配给合适的项目成员，充分发挥其才能）
是否为了节省钱，不采用（购买）成熟的软件模块，一切从零做起？
子承包商
供应商
与子承包商、供应商签订的合同公正吗？双方互利吗？
子承包商、供应商的信誉好吗？
子承包商、供应商有可能倒闭吗？
子承包商、供应商能及时交付质量合格的产品（或部件）吗？
子承包商、供应商有能力做好售后服务吗？
管理风险
风险类型
检查项
项目计划
对项目的规模、难度估计是否比较正确？
人力资源（开发人员、管理人员）够用吗？合格吗？
…
项目团队
项目成员团结吗？是否存在矛盾？
是否绝大部分的项目成员对工作认真负责？
绝大部分的项目成员有工作热情吗？
团队之中有“害群之马”吗？
技术开发队伍中有临时工吗？
本项目开发过程中是否会有核心人员辞职、调动？
是否能保证“人员流动基本不会影响工作的连续性”？
项目经理是否忙于行政事务而无暇顾及项目的开发工作？
机构是否有较好的奖励和惩罚措施？
本项目的合作部门的态度积极吗？是否应付了事？或者做事与承诺的不一致？
技术风险
风险类型
检查项
需求开发
需求管理
需求开发人员懂得如何获取用户需求吗？效率高吗？
需求开发人员懂得项目所涉及的具体业务吗？能否理解用户的需求？
需求文档能够正确地、完备地表达用户需求吗？
项目风险检查表完整版
参数
等级
值
描述
风险
可能性
很高
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％
需求文档能够正确地、完备地表达用户需求吗？
需求开发人员能否与客户对有争议的需求达成共识？
需求开发人员能否获得客户对需求文档的承诺？以保证客户不随便变更需求？
综合技术
开发能力
包括设计
编程、测试等
开发人员是否有开发相似产品的经验？
待开发的产品是否要与未曾证实的软硬件相连接？
对开发人员而言，本项目的技术难度高吗？
软件项目检查表
软件项目检查表
项目概述
该软件项目检查表旨在帮助团队对软件项目进行全面的检查和
评估，以确保项目的顺利进行和高质量的交付。
本检查表包括多个
方面，包括项目计划、需求分析、设计、开发、测试和部署等环节。
项目计划
- 项目是否有明确的目标和可行的计划？
- 是否有详细的项目计划及时间表？
- 是否有项目经理负责监督和管理项目进度？
需求分析
- 是否完整、准确地收集和记录了项目的需求？
- 是否对需求进行了合理的分类和优先级排序？
- 是否与相关利益相关者沟通确认了需求？
设计
- 是否进行了系统的架构设计和模块设计？
- 是否充分考虑了扩展性和可维护性等因素？
- 是否进行了界面设计和交互设计？
开发
- 是否按照设计文档进行开发工作？
- 是否按照编码规范完成代码编写？
- 是否进行了代码评审和单元测试？
测试
- 是否制定了详细的测试计划和测试用例？
- 是否进行了功能测试、性能测试和安全测试等多个方面的测试？
- 是否及时修复了测试中发现的缺陷和问题？
部署
- 是否制定了可靠的部署计划？
- 是否进行了部署前的完整测试和验证？
- 是否提供了必要的文档和培训？
运维支持
- 是否确保了系统的可靠性和稳定性？
- 是否建立了监控和报警机制？
- 是否保障了系统的安全性和数据的完整性？
以上是软件项目检查表的主要内容，通过对每个方面的检查和评估，能够有效提升软件项目的质量和成功交付的概率。
请针对具体项目的不同需求和情况，适当调整和完善该检查表。
软件项目风险检查表模板
严重
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、项目使命已经通知到了所有参与者。
3、已经识别风险，并在可能的情况下编制了应急措施。
4、核实P、C、T、S可行性的项目战略。
5、满意的力场分析。
6、已对后果进行了分析并且是可接受的。
7、所有项目人员都理解了项目的最终目标。
8、至少对变量P、C、T、S其中之一进行了估算，而不是指定所有四个变量。
9、有项目绩效需求的明确定义。
10、有评估绩效目标的合适标准。
11、编制出的项目分解结构的级数足以使成本、时间和资源需求的估算达到满意的准确度。
12、WBS已接受如下审查：客户、贡献者、高级管理层。
13、按照计划进行审查的进度里程碑已经确立。
14、遵照WBS，已经完成了网络形式的任务级进度计划。
15、已经识别出关键路径。
16、关键路径可以满足要求的结束时间。
17、为确定关键路径是否现实，对其进行了检查。
18、作为工作工具，编制了甘特图。
19、为确保资源没有过载，检查了资源分配。
20、不要以高于80%的生产率进行资源分配。
21、消除和解决了与其他项目的资源冲突。
22、已经设计出控制系统。
23、已经建立了项目评估方法。
24、执行项目计划的人员应参与计划编制。
25、计划应在合适的级别（既不能太大，也不能太小）。
26、如果可能，估算应基于类似项目的记录。
27、估算扩充已公开完成。
28、对于管理层来说，扩充应可接受。
29、项目计划已经在最终确认会上审查通过。
30、项目笔记已由项目干系人签署。
31、最终确认会上提出的所关心的问题已得到令每个人都满意的解决。
32、计划包括以下内容：问题说明、使命说明、项目战略、项目目标、QFD分析或识别客户需求的其他方法、SWOT分析、项目范围说明、可交付成果清单或其他合同要求、需达到的成品规范、工作分解结构、里程碑和任务级进度计划、资源需求、控制系统（包括变更控制程序）、以线性责任图形式表示的主要贡献者、风险分析和应急措施、要求的工作说明。
防病毒防恶意软件安全检查表
防病毒防恶意软件安全检查表介绍本文档为防病毒和防恶意软件安全检查表，用于确保计算机系统和网络的安全。
通过定期检查以下项目，可以有效减少病毒和恶意软件对系统的威胁。
安全检查项目1. 病毒防护软件- 检查计算机系统是否安装了最新版本的病毒防护软件。
- 确保病毒防护软件的病毒数据库处于最新状态。
- 验证病毒防护软件是否启用了实时保护功能。
2. 恶意软件防范- 检查计算机系统是否安装了恶意软件防范工具。
- 确保恶意软件防范工具的恶意软件数据库处于最新状态。
- 验证恶意软件防范工具是否启用了实时检测功能。
3. 系统安全更新- 确认操作系统是否安装了最新的安全更新补丁。
- 检查应用程序及浏览器是否安装了最新的安全更新。
4. 邮件和文件下载安全- 教育员工要警惕电子邮件附件中的潜在风险，特别是来自不明来源的邮件。
- 建议员工只从可信任的网站下载文件，避免下载未知来源的文件。
5. 强密码和账户安全- 强调员工使用强密码，并定期更改密码。
- 确保员工账户没有共享密码，避免使用相同密码多次。
6. 网络防火墙- 确保网络防火墙已正确配置，阻止未经授权的访问。
- 定期检查网络防火墙的日志，以便发现异常活动并采取相应措施。
7. 员工培训和意识- 提供有关病毒和恶意软件的培训，以加强员工对安全威胁的认识。
- 教育员工如何识别和应对可能存在的安全风险。
结束语执行本检查表的内容将有助于保护计算机系统和网络免受病毒和恶意软件的侵害。
建议定期复查和更新检查表，以适应不断变化的安全威胁。
项目风险检查表
风险严重性等级参数等级值描述风险严重性很高5例如进度延误大于30％，或者费用超支大于30％比较高4例如进度延误20%－30％，或者费用超支20%－30％中等3例如进度延误低于20％，或者费用超支低于20％比较低2例如进度延误低于10％，或者费用超支低于10％很低1例如进度延误低于5％，或者费用超支低于5％风险可能性等级参数等级值描述风险可能性很高5风险发生的几率为～比较高4风险发生的几率为～中等3风险发生的几率为～比较低2风险发生的几率为～很低1风险发生的几率为～风险系数等级风险系数风险可能性很高5比较高4中等3比较低2很低1风险严重性很高5252015105较高420161284中等31512963比较低2108642很低154321本表灰色部分的风险系数为10～25，应当优先处理风险检查表商业风险风险类型检查项政治法律市场政府或者其它机构对本项目的开发有限制吗？有不可预测的市场动荡吗？有不利于我方的官司要打吗？本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗？竞争对手有不正当的竞争行为吗？本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗？是否在开发很少有人真正需要却自以为很好的产品？是否在开发可能亏本的产品？客户客户的需求是否含糊不清？客户是否反反复复地改动需求？客户指定的需求和交付期限在客观上可行吗？客户对产品的健壮性、可靠性、性能等质量因素有非常过分的要求吗？客户的合作态度友善吗？与客户签的合同公正吗？双方互利吗？客户的信誉好吗？例如按客户的需求开发了产品，但是客户可能不购买。
子承包商供应商与子承包商、供应商签订的合同公正吗？双方互利吗？子承包商、供应商的信誉好吗？子承包商、供应商有可能倒闭吗？子承包商、供应商能及时交付质量合格的产品（或部件）吗？子承包商、供应商有能力做好售后服务吗？管理风险风险类型检查项项目计划对项目的规模、难度估计是否比较正确？人力资源（开发人员、管理人员）够用吗？合格吗？项目所需的软件、硬件能按时到位吗？项目的经费够用吗？进度安排是否过于紧张？有合理的缓冲时间吗？进度表中是否遗忘了一些重要的（必要的）任务？进度安排是否考虑了关键路径？是否可能出现某一项工作延误导致其它一连串的工作也被延误？任务分配是否合理？（即把任务分配给合适的项目成员，充分发挥其才能）是否为了节省钱，不采用（购买）成熟的软件模块，一切从零做起？…项目团队项目成员团结吗？是否存在矛盾？是否绝大部分的项目成员对工作认真负责？绝大部分的项目成员有工作热情吗？团队之中有“害群之马”吗？技术开发队伍中有临时工吗？本项目开发过程中是否会有核心人员辞职、调动？是否能保证“人员流动基本不会影响工作的连续性”？项目经理是否忙于行政事务而无暇顾及项目的开发工作？上级领导行政部门合作部门本项目是否得到上级领导的重视？上级领导是否随时会抽调本项目的资源用于其它“高优先级”的项目？上级领导是否过多地介入本项目的事务并且瞎指挥？行政部门的办事效率是否比较底，以至于拖项目的后腿？行政部门是否经常干一些无益于生产力的事情，以至于骚扰本项目？机构是否能全面、公正地考核员工的工作业绩？机构是否有较好的奖励和惩罚措施？本项目的合作部门的态度积极吗？是否应付了事？或者做事与承诺的不一致？技术风险风险类型检查项需求开发需求开发人员懂得如何获取用户需求吗？效率高吗？需求管理需求开发人员懂得项目所涉及的具体业务吗？能否理解用户的需求？需求文档能够正确地、完备地表达用户需求吗？需求开发人员能否与客户对有争议的需求达成共识？需求开发人员能否获得客户对需求文档的承诺？以保证客户不随便变更需求？综合技术开发能力包括设计编程、测试等开发人员是否有开发相似产品的经验？待开发的产品是否要与未曾证实的软硬件相连接？对开发人员而言，本项目的技术难度高吗？开发人员是否已经掌握了本项目的关键技术？如果某项技术尚未实践过，开发人员能否在预定时间内掌握？开发小组是否采用比较有效的分析、设计、编程、测试工具？分析与设计工作是否过于简单、草率，从而让程序员边做边改？开发小组采用统一的编程规范吗？开发人员对测试工作重视吗？能保证测试的客观性吗？项目有独立的测试人员吗？懂得如何进行高效率地测试吗？是否对所有重要的工作成果进行了同行评审（正式评审或快速检查）？开发人员懂得版本控制、变更控制吗？能够按照配置管理规范执行吗？开发人员重视质量吗？是否会在进度延误时降低质量要求？。
软件设计与开发评审检查表
是否执行输入、输出、接口和结果的错误检查？
是否对所有错误情况都发出故意义的信息？
对特殊情况返回的代码是否和已规定的全局定义的返回代码相匹配？
是否考虑到意外事件？
易测性
是否可以对每个单元进行测试、演示、分析或检查来说明它们是满足需求的？
该套系统是否能用增量型的方法来集成和测试？
可追溯性
是否各部分的设计都能追溯到需求说明书的需求？
是否所有的设计决策都能追溯到本来拟定的权衡因素?
所继承设计的已知风险是否已拟定和分析？
具体设计检查表
Y: 是 TBD: 不拟定 N: 不是 NA:不合用
检查项
Y/TBD/N/NA
清楚性
所有单元或过程的目的是否都已文档化？
一致性
数据元素的命名和使用在整个单元和单元接口之间是否一致？
所有接口的设计是否互相一致并且和更高级别文档一致？
对的性
是否解决所有条件 （大于、等于、小于零、switch/case）？ 是否存在解决“case not found”的条件？
是否对的地规定了分支（逻辑没有颠倒）？
数据使用
是否所有声明的数据都被实际使用到？
Y: 是 TBD: 不拟定 N: 不是 NA:不合用
备注
检查项
Y/TBD/N/NA
清楚性
系统的目的是否已定义？
是否对关键术语和缩略语进行定义和描述？
所使用的术语是否和用户/客户使用的一致？
需求的描述是否清楚, 不模糊？
是否有对整套系统进行功能概述？
是否已具体说明了软件环境 (共存的软件) 和硬件环境 (特定的配置)？
风险对照检查表
本项目的合作部门的态度积极吗？是否应付了事？或者做事与承诺的不一致？
技术风险
风险类型
检查项
评分（1~5）
需求开发
需求管理
需求开发人员懂得如何获取用户需求吗？效率高吗？
需求开发人员懂得项目所涉及的具体业务吗？能否理解用户的需求？
需求文档能够正确地、完备地表达用户需求吗？
需求开发人员能否与客户对有争议的需求达成共识？
需求开发人员能否获得客户对需求文档的承诺？以保证客户不随便变更需求？
综合技术
开发能力
包括设计
编程、测试等
开发人员是否有开发相似产品的经验？
待开发的产品是否要与未曾证实的软硬件相连接？
对开发人员而言，本项目的技术难度高吗？
开发人员是否已经掌握了本项目的关键技术？
子承包商
供应商
与子承包商、供应商签订的合同公正吗？双方互利吗？
子承包商、供应商的信誉好吗？
子承包商、供应商有可能倒闭吗？
子承包商、供应商能及时交付质量合格的产品（或部件）吗？
子承包商、供应商有能力做好售后服务吗？
管理风险
风险类型
检查项
评分（1~5）
项目计划
对项目的规模、难度估计是否比较正确？
人力资源（发人员、管理人员）够用吗？合格吗？
项目所需的软件、硬件能按时到位吗？
项目的经费够用吗？
进度安排是否过于紧张？有合理的缓冲时间吗？
进度表中是否遗忘了一些重要的（必要的）任务？
进度安排是否考虑了关键路径？
是否可能出现某一项工作延误导致其它一连串的工作也被延误？
任务分配是否合理？（即把任务分配给合适的项目成员，充分发挥其才能）
是否为了节省钱，不采用（购买）成熟的软件模块，一切从零做起？
项目风险检查表模板
风险点数总计不超过5，且不存在小风险以上的风险时，可行性评审通过。
顾客交货要求能不能接受？
0
顾客的责任/义务能不能接受？
0
顾客的履行情况和合法收入情况是否可接受？
0
工具所有权有没有说明？
0
包装规范有没有说明？
0
合同期限有没有说明？
0
合同类型（长期合同还是终身合同）有没有说明？
0
份额有没有说明？
0
竞争者的情况是否了解？
项目风险检查表模板
项目代号：
零部件号：
零件名称：
新项目 ■
设计变更 □
风险点数总计：
0
风险评价：0=无风险 1=小风险 2=中风险 3=高风险
风险点数总计不超过5，且不存在小风险以上的风险时，可行性评审通过。
A. 技术/专门测试
风险
1 产品要素
有没有类似产品的经验？
0
从类似产品中是否可以得知风险：
0
1 要求
生产场所缺乏吗？
0
生产设备缺乏吗？
0
生产人员缺乏吗？
0
2 时间表
设计能力缺乏吗？
0
生产装备能力缺乏吗？
0
连续生产的能力缺乏吗？
0
C. 管理和按规定检查
1 财务预期
当过程实现时，成本是否很难预测？
0
预计的返工是否造成潜在的成本提高？
0
外购件汇率的风险大吗？
0
报价的货币汇率风险高吗？
0
对顾客的要求有没有负面影响？
0
生产能力风险大吗？（太低了）
0
数量增加时预估的成本增加风险高吗？
0
新的生产场所投资风险高吗？
0
软件项目风险管理计划-模板
1变更履历目录1简介 (4)1.1目的 (4)1.2范围 (4)1.3定义、首字母缩写词和缩略语 (4)1.4引用 (4)2风险概要 (6)3风险管理任务 (6)4组织和职责 (6)5预算 (6)6工具和技术 (6)7风险项和风险管理策略 (7)1简介根据生产管理信息系统移动端系统过程中可能会出现的问题我们制定了该风险管理计划。
1.1目的该计划的目的是为了规范风险管理流程，使项目的进度不会因为风险的发生而发生变化。
1.2范围该计划作用的范围是在整个软件开发过程中会发生风险的所有阶段。
1.3定义、首字母缩写词和缩略语⏹RSKM：风险管理（Risk Management）⏹DM：部门经理（Department Manager）⏹PM：项目经理（Project Manager）⏹QA：质量保证人员（Quality Assurance）⏹CM：配置管理员（Configuration Management）⏹DevG：开发组（Development Group）⏹TG：测试组（Test Group）⏹RevG：评审组（Review Group）⏹SE：系统工程师（System Engineer）⏹SD：系统设计人员（System Designer）⏹DBD：数据库设计人员（DataBase Designer）⏹PG：程序员（Programmer）1.4引用此部分引用的文档有：风险管理一览表(XXX-XTYDD-rskm-chk&tracking)v1.0.xls风险检查表(XXX-XTYDD-rskm-rc)v1.0.xls风险管理过程文件(XXX-SPI-RSKM-Proc-Doc)V1.1.doc风险管理指南(XXX-SPI-RSKM-Guid-Management)V1.0.doc2风险概要根据该项目的实际情况发现在该项目开发过程中可能会遇到以下几个风险：估算风险，进度风险，技术风险和人事风险。
软件项目设计评审检查表
技能水平及其他因素？
1.3
系统架构是否考虑了性能、安全、可扩展 、维护性等因素
1.4
系统架构是否有利于充分发挥现有硬件资 源的效能？
系统架构是否有利于在应用环境中的部
1.5
署？是否有利于系统管理员进行管理、维
护？
各个层的划分是否合理，各个层之间是否
1.6
有清晰的功能划分？是否符合主流的分层 规则（界面、业务逻辑、业务对象、数据
3.15 表或实体设计命名是否符合规范？
4
界面设计
是否描述项目所需要实现的各种典型界面
4.1
并给出界面demo？
是否遵循软件界面设计指南的要求？界面
4.2
风格的美学要求？
界面操作是否足够的人性化，能够获得交 好的用户体验？ 4.3
版本号：2 修订号：0
第3页 共3页
访问等）？
系统功能模块的划分是否合理，是否符合
1.7
用户的实际业务操作方式？是否与用户的
岗位分工保持一致？
1.8
每个模块的功能、职责是否定义清楚？
1.9
各个模块的接口（通信界面）是否定义清 楚，以利于与其它系统的交互以及集成？
1.10
是否充分考虑到架构或组件的复用。
1.11
是否充分考虑了系统实现技术上的风险和 解决办法？
2
模块设计
版本号：2 修订号：0
缺陷描述第1页 共3页 Nhomakorabea 2.1
功能模块的设计文字说明是否清晰，比 较好的表达问题？
界面类设计布局及界面包含元素是否合
理，界面的显示或功能操作是否涵盖对
2.2
应的模块功能？是否能够满足人机交互 的友好性？界面类是否耦合了业务逻辑
【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维护阶段是否对维护过程记录了？。
公司对项目部工作检查表
公司对项目部工作检查表一、项目概述项目名称：项目负责人：项目周期：项目目标：项目背景：二、项目计划1. 项目计划是否合理、可行？2. 项目进度是否符合计划？3. 是否存在关键节点的延迟？4. 项目资源是否合理调配？5. 是否存在冲突和问题的解决方案？三、项目组织与沟通1. 项目团队是否明确？2. 项目成员是否清楚各自职责？3. 项目沟通是否顺畅？4. 是否有必要召开项目进展会议？5. 是否存在沟通障碍和解决方案？四、项目风险管理1. 是否制定了完备的风险管理计划？2. 是否定期进行风险评估和监控？3. 是否及时采取措施应对风险事件？4. 是否存在潜在的风险和应对策略？5. 是否有必要调整项目计划以应对风险？五、项目质量管理1. 是否建立了合适的质量管理体系？2. 是否制定了质量标准和评估方法？3. 是否进行了质量检查和测试？4. 是否存在质量问题和改进措施？5. 是否有必要调整项目计划以提高质量？六、项目成本管理1. 是否制定了合理的成本控制措施？2. 是否进行了成本预算和监控？3. 是否存在超出预算的情况？4. 是否进行了成本效益分析？5. 是否有必要调整项目计划以控制成本？七、项目绩效评估1. 是否制定了绩效评估指标和方法？2. 是否进行了定期绩效评估？3. 是否存在绩效问题和改进措施？4. 是否有必要调整项目计划以提高绩效？5. 是否及时奖惩绩效优良或差劣的成员？八、项目总结与反思1. 项目取得的成果和经验教训？2. 是否进行了项目总结和归档？3. 是否提供了反馈和建议？4. 是否有必要调整项目管理方法和流程？5. 是否有必要进行改进和学习？以上为公司对项目部工作的检查表，通过对每个环节的评估和检查，可以及时发现问题并提出改进措施，确保项目顺利进行并达到预期目标。
同时，项目管理团队也应根据实际情况对检查表进行适当调整和优化，以提高工作效率和质量。
软件产品开发风险检查方法
软件产品开发风险检查方法软件产品开发风险检查表（一）软件需求与风险管理（二）所谓风险是可能给项目的成功带来威胁或损失的情况。
这种情况还没有发生，也没有带来问题，而你希望它永远不会发生。
但这些潜在的问题可能会给项目成本费用、进度安排、技术方面、产品质量及团队工作效率等带来较大的负面影响。
而风险管理—一种软件工业的最佳方法—就是在风险给项目带来损失之前，就指明、评估并对风险加以控制。
如果不希望发生的事已经发生了，那就不再是风险，而是事实了。
只好通过项目事务( 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）的方法来管理那些已被发现为高优先级的风险。
制定风险管理计划是一项处理具有一旦发生，影响较大的风险的计划，包括降低风险的方法、应急计划、负责人和截止日期。
应尽量避免让风险成为真正的问题，或即便问题发生了，也应尽量让其影响降低到最小。
风险不能够自我控制，所以风险解决方案就包括了降低、减少每项风险的执行计划。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
修改记录页
目录
1.引言 (3)
1.1目的 (3)
1.2适用范围 (3)
1.3角色与职责 (3)
2.风险检查参考列表 (3)
1. 引言
1.1 目的
风险检查表的目的是提供风险检查参考列表，在实施项目的过程中，根据本表生成该项目的风险管理卡，识别该项目潜在的风险，以便策划应对风险的活动和在整个项目生存周期中实施这些活动，缓解并消除潜在的风险。
1.2 适用范围
本文档作为项目风险识别的初始依据和指导，使用者根据本机构和项目的实际情况不断地完善本表内容。
1.3 角色与职责
2. 风险检查参考列表。