搜索
中国广东核电集团CHINAGUANGDONGNUCLEARPOWERGROUP记录文件项目编号项目名称CGN-IT-C3-A07-01软件项目风险检查表版本编写审核审定批准生效时间A/0注：如无受控文件标识（蓝色印章）则为非有效版本，以受控文件规定为准。此文件属中国广东核电集团有限公司所有，未经许可，不得以任何方式外传。页码：1修改记录页NO修改日期修改摘要（涉及页码/条款/内容）版本修改原因页码：2目录1.引言............................................................................................................31.1目的..............................................................................................................................31.2适用范围.......................................................................................................................31.3角色与职责...................................................................................................................32.风险检查参考列表......................................................................................3页码：31.引言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软件最后用户数量大大超过最初设计数量？页码：4承包商/供应商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需求文档能够正确表达客户的需求吗？页码：518需求文档对开发人员阅读有困难吗？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用户是否对确认的需求做出承诺？页码：64项目成员是否能够根据需求整理出用户使用文档？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维护阶段是否对维护过程记录了？