软件项目风险检查表.doc
- 文档编号:1294887
- 上传时间:2023-04-30
- 格式:DOC
- 页数:7
- 大小:287KB
软件项目风险检查表.doc
《软件项目风险检查表.doc》由会员分享,可在线阅读,更多相关《软件项目风险检查表.doc(7页珍藏版)》请在冰点文库上搜索。
中国广东核电集团
CHINAGUANGDONGNUCLEARPOWERGROUP
记录文件
项目编号
项目名称
CGN-IT-C3-A07-01
软件项目风险检查表
版本
编写
审核
审定
批准
生效时间
A/0
注:
如无受控文件标识(蓝色印章)则为非有效版本,以受控文件规定为准。
此文件属中国广东核电集团有限公司所有,未经许可,不得以任何方式外传。
修改记录页
NO
修改日期
修改摘要(涉及页码/条款/内容)
版本
修改原因
目录
1. 引言 3
1.1 目的 3
1.2 适用范围 3
1.3 角色与职责 3
2. 风险检查参考列表 3
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
需求文档是否整理出usecase?
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
维护阶段是否对维护过程记录了?
页码:
6
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 项目风险 检查表