常见软件项目风险检查表
来源:动视网
责编:小OO
时间:2025-09-24 08:54:56
常见软件项目风险检查表
软件项目风险检查表修改记录页NO修改日期修改摘要(涉及页码/条款/内容)版本修改原因1.引言1.1目的风险检查表的目的是提供风险检查参考列表,在实施项目的过程中,根据本表生成该项目的风险管理卡,识别该项目潜在的风险,以便策划应对风险的活动和在整个项目生存周期中实施这些活动,缓解并消除潜在的风险。1.2适用范围本文档作为项目风险识别的初始依据和指导,使用者根据本机构和项目的实际情况不断地完善本表内容。1.3角色与职责角色职责项目经理(PM)总体负责识别项目的风险并给出应对策略项目成员识别项目的风
导读软件项目风险检查表修改记录页NO修改日期修改摘要(涉及页码/条款/内容)版本修改原因1.引言1.1目的风险检查表的目的是提供风险检查参考列表,在实施项目的过程中,根据本表生成该项目的风险管理卡,识别该项目潜在的风险,以便策划应对风险的活动和在整个项目生存周期中实施这些活动,缓解并消除潜在的风险。1.2适用范围本文档作为项目风险识别的初始依据和指导,使用者根据本机构和项目的实际情况不断地完善本表内容。1.3角色与职责角色职责项目经理(PM)总体负责识别项目的风险并给出应对策略项目成员识别项目的风
软件项目风险检查表
修改记录页
| NO | 修改日期 | 修改摘要(涉及页码/条款/内容) | 版本 | 修改原因 |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
1.引言
1.1目的
风险检查表的目的是提供风险检查参考列表,在实施项目的过程中,根据本表生成该项目的风险管理卡,识别该项目潜在的风险,以便策划应对风险的活动和在整个项目生存周期中实施这些活动,缓解并消除潜在的风险。
1.2适用范围
本文档作为项目风险识别的初始依据和指导,使用者根据本机构和项目的实际情况不断地完善本表内容。
1.3角色与职责
| 角色 | 职责 |
| 项目经理(PM) | 总体负责识别项目的风险并给出应对策略 |
| 项目成员 | 识别项目的风险并给出应对策略 |
| SQA人员 | 参照本表和质量管理流程进行质保活动 |
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 | 是否有人对项目或者技术产生抵触,并进行破坏? |
| 2 | SQA人员是否积极按照制度参与项目的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 | 用户参与测试是否积极?参与力度是否足够? |
| SCM | 1 | 配置管理人员是否有足够的知识技能? |
| 2 | 代码和文档的备份能够达到每天1次,连续30天吗? |
| 3 | 能够随时抽出以前的任一基线的代码版本吗? |
| 4 | 开发人员掌握了配置管理工具的使用技能吗? |
| 验收 | 1 | 用户参与验收力度是否足够? |
| 2 | 验收文档清单中的列表项是否都满足? |
| 3 | 验收计划是否合理? |
| 维护 | 1 | 维护人员具有足够的维护知识技能吗? |
| 2 | 维护人员是否足够? |
| 3 | 维护阶段是否对维护过程记录了? |
常见软件项目风险检查表
软件项目风险检查表修改记录页NO修改日期修改摘要(涉及页码/条款/内容)版本修改原因1.引言1.1目的风险检查表的目的是提供风险检查参考列表,在实施项目的过程中,根据本表生成该项目的风险管理卡,识别该项目潜在的风险,以便策划应对风险的活动和在整个项目生存周期中实施这些活动,缓解并消除潜在的风险。1.2适用范围本文档作为项目风险识别的初始依据和指导,使用者根据本机构和项目的实际情况不断地完善本表内容。1.3角色与职责角色职责项目经理(PM)总体负责识别项目的风险并给出应对策略项目成员识别项目的风