软件项目风险检查表

中国广东核电集团中国广东核电集团 CHINA GUANGDONG NUCLEAR POWER GROUPCHINA GUANGDONG NUCLEAR POWER GROUP 记记 录录 文文 件件 项目编号项目编号 项目名称项目名称 CGN-IT-C3-A07-01CGN-IT-C3-A07-01 软件项目风险检查表软件项目风险检查表 版本 A/0 编写审核审定批准生效时间 注：如无受控文件标识（蓝色印章）则为非有效版本，以受控文件规定为准。 此文件属中国广东核电集团有限公司所有，未经许可，不得以任何方式外传。 修改记录页修改记录页 NO修改日期修改摘要（涉及页码/条款/内容）版本修改原因 页码：1 1.1. 目目录录 引言引言. 3. 3 1.1目的 3 1.2适用范围. 3 1.3角色与职责. 3 2.2.风险检查参考列表风险检查参考列表 3 3 页码：2 1.1.引言引言 1.11.1目的目的 风险检查表的目的是提供风险检查参考列表，在实施项目的过程中，根据本表生成 该项目的风险管理卡，识别该项目潜在的风险，以便策划应对风险的活动和在整个项目 生存周期中实施这些活动，缓解并消除潜在的风险。 1.21.2适用范围适用范围 本文档作为项目风险识别的初始依据和指导，使用者根据本机构和项目的实际情况 不断地完善本表内容。 1.31.3角色与职责角色与职责 职责职责 总体负责识别项目的风险并给出应对策略 识别项目的风险并给出应对策略 参照本表和质量管理流程进行质保活动 角色角色 项目经理(PM) 项目成员 SQA 人员 2.2.风险检查参考列表风险检查参考列表 风险类型风险类型 政治/法律 客户 商业风险商业风险 风险来源风险来源 1政府或者其它机构是否对本项目的开发有限制？ 2项目中间有没有产品存在版权纠纷？ 3项目会不会对个人隐私造成干扰？ 4项目是否使用了非法数据？ 5项目是否产生了非法数据？ 6投标商是否可能采用了非法的竞争手段？ 1客户合作态度是否友善？ 2客户在项目上是否有准备出足够的时间？ 3客户的人员数目是否足够？ 4客户的业务是否足够熟练并胜任本项目？ 5客户的各领导层是否支持本项目？ 6客户部门内或者外是否有人对项目持否定态度？ 7客户的历史合作信誉度如何？ 8客户是否易反复而不信守承诺？ 9客户是否对项目有不符实际的较高要求？ 10软件最后用户数量大大超过最初设计数量？ 页码：3 承包商/供应商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 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 与承包商/供应商签订的合同公正吗？互利吗？ 承包商/供应商的信誉好吗？ 承包商/供应商是否容易倒闭？ 承包商/供应商的售后服务有保证吗？ 承包商/供应商的人员队伍稳定吗？ 承包商/供应商的历史项目是否非常成功？ 承包商/供应商的人员结构是否合理？ 承包商/供应商能提供给本项目的合适的人员吗？ 承包商/供应商是否为了应对本项目而临时招聘人员？ 承包商/供应商是否可能撤出本项目的市场而转型？ 承包商/供应商是否为了拿到项目而故意降低报价？ 承包商/供应商的报价是否已经离我方估算偏差较大？ 承包商/供应商是否有追加变更而赚取利润的企图？ 项目风险项目风险 风险来源风险来源 项目组是否能够准确把握项目规模？ 项目组是否真正地理解了客户需求？ 是否根据需求进行了估算，估算方法是否合理？ 估算的成本是否高于预算经费却不能得到足够经费？ 是否需要采购软硬件开发设备？能否及时到位？ 人力资源的配置能够满足项目的需要吗？ 进度计划安排是否过于紧张？ 有没有合理的项目缓冲时间？ 进度计划表是否覆盖所有研发任务？ 任务的分配能够充分发挥团队成员的积极能动性吗？ 是否明确项目进度阶段里程碑？ 是否有人对项目或者技术产生抵触，并进行破坏？ SQA 人员是否积极按照制度参与项目的 QA 工作？ 项目成员是否团结？工作氛围是否活跃？ 成员表达沟通能力是否让管理层满意？ 是否制定奖赏惩罚措施？奖赏惩罚措施是否严格执行？ 临时成员是否占项目成员的较大比率？ 人员变动包括核心人员吗？ 项目成员是否明确自己的职责？ 项目经理或者调研人员能够及时与客户进行沟通吗？ 沟通的氛围是否友好？沟通的效率高不高？ 项目的成员有相关工作的经验吗？ 客户的表达能力是否强？ 我方的理解能力是否强？ 客户是否理解我方对客户需求的分析说明？ 项目组人员是否懂得项目相关的具体业务知识？ 具体业务有没有行业规范参考？ 需求文档能够正确表达客户的需求吗？ 页码：4 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 3 需求文档对开发人员阅读有困难吗？ 需求有没有存在争议？ 项目资源的分配会不会随时被抽调到别的项目？ 本项目的合作部门的态度是否积极？ 项目组人员是否能够严格遵守项目管理制度？ 技术风险技术风险 风险来源风险来源 开发人员是否有开发相似产品的经验？ 核心人员对技术的熟悉程度是不是达到要求？ 项目研发的核心技术是不是为开发人员所掌握？ 若技术从来没有接触过，开发人员是否有足够的学习能力？ 项目中是否有一些人员只能部分时间工作 开发人员是否接受过必要的培训? 项目开发人员是否配套？ 开发小组是否采用比较有效的分析、设计、编程、测试工具？ 分析与设计工作是否过于简单、草率，从而让程序员边做边 改？ 开发人员对测试工作重视吗？ 项目有独立的测试人员吗？ 测试人员掌握了相关测试工具和方法了吗？ 是否对重要的工作成果进行同行评审？ 开发人员有没有进行版本控制？ 管理人员有没有进行变更控制措施和制度措施保证？ 配置人员能够按照配置管理规范执行吗？ 是否会在进度延误时降低质量要求？ 项目成员是否按照度量规范记录相关内容? 待开发的产品是否要与其它软件有接口？ 待开发的产品是否要应用未曾接触的开发架构？ 待开发的产品是否要使用未曾接触的开发工具？ 待开发的产品是否要使用未曾使用过的开发技术？ 待开发的产品是否要部署在未曾接触的硬件环境？ 设计工具存在多样选择吗？设计工具统一吗？ 设计文档样式有明确规定吗？ 开发小组采用统一的编程规范吗？ 由于功能复杂，导致项目编程语言种类繁多吗？ 维护工作有没有采用专门工具进行跟踪管理？ 因为维护产生的代码修改有没有及时纳入版本控制？ 维护范围、进度、人员、规范的定义是否明确？ 开发阶段风险开发阶段风险 风险来源风险来源 用户的需求是否合理？ 需求文档是否整理出 use case? 用户是否对确认的需求做出承诺？ 页码：5 设计阶段 代码开发 测试 SCM 验收 维护 4 5 6 7 8 9 10 11 1 2 3 4 5 6 7 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 1 2 3 项目成员是否能够根据需求整理出用户使用文档？ 用户需求是否有不断膨胀、不断变化的危险？ 是否有工作量