| |
|
|
|
|
|
| |
项目相关的风险要素及分类 |
| |
|
|
|
|
|
| |
用户角度的要素及分类 |
|
| |
|
|
|
|
|
| 编号 |
风险要素 |
低风险 |
中等风险 |
高风险 |
等级 |
| |
|
|
|
|
|
| |
客户的任务和目标 |
|
|
|
| 1 |
项目是否符合客户的目标 |
完全符合客户的目标 |
一个或几个客户的目标不能直接实现 |
基本不能达到客户的目标 |
|
| 2 |
对客户原有工作流程的影响 |
基本保持客户原有的工作流程 |
某些工作流程会因为本项目而受到小的影响 |
客户的工作流程和方法将因本项目的实施而产生很大的变化 |
|
| |
客户的机构管理 |
|
|
|
| 3 |
客户机构的稳定性 |
基本不会发生变化 |
会发生较小的变化 |
客户的机构或管理方式会发生持续的或迅速的变化 |
|
| 4 |
客户机构中的人员及责任 |
每一个人都很清楚自己及他人的角色和工作责任 |
每一个人都清楚自己的角色和工作责任，但并不清楚其他人的责任 |
客户机构中的大多数人都不清楚自己或他人的工作职责 |
|
| 5 |
政策和标准 |
有详细的政策与标准并严格遵守 |
有政策与标准，但没有很强的约束力 |
没有政策或标准，或制订不正确而没有执行 |
|
| 6 |
管理层的支持 |
强力支持本项目的成功 |
有一些承诺，但不完全支持 |
几乎不支持本项目 |
|
| 7 |
执行层的支持 |
有很强的支持 |
当被要求时，有有限的支持 |
没有有效的支持 |
|
| 8 |
项目目标 |
需求合理，目标有效 |
有一些项目目标，但衡量标准有一些问题 |
没有明确的目标，或目标无法衡量 |
|
| 9 |
做出决议的流程 |
决议可以由一个负责人或一个固定的小规模的团体作出 |
决议必须在固定的例会上由领导层决定 |
决议由一群管理人员作出，但这些人员没有固定的决议方法，也没有领导人员 |
|
| 10 |
客户的衡量标准 |
对业务是否成功和信息技术对业务的影响，客户有成熟的衡量标准 |
IT客户对业务的某些方面有衡量标准，但可能没有标准衡量信息技术对业务的影响 |
几乎没有标准来衡量业务及信息技术对业务的影响 |
|
| 11 |
客户组织成员的参与程度 |
项目组可以与客户所有需要交流的部门进行足够的交流 |
项目组不能确认是否能够与所有需要交流的部门进行足够的沟通 |
项目组与客户组织中的一个或数个关键部门进行交流，或这些部门之间没有交流，或项目组与某个关键部门的交流将影响项目组与其他部门的交流 |
|
| |
客户/最终用户 |
|
|
|
|
| 12 |
最终用户在项目中的参与程度 |
最终用户紧密参与项目开发，并有重要的作用 |
最终用户在项目中扮演次要的角色，对项目的贡献为中等程度 |
几乎没有最终用户的参与，最终用户对项目也几乎没有意见和建议 |
|
| 13 |
最终用户的使用经验 |
用户在类似项目上有丰富的使用经验，对如何达到需求有明确的思路 |
用户有类似系统的使用经验，并且有关于需求的想法 |
用户几乎没有任何类似系统的使用经验，也不知道如何达到需求 |
|
| 14 |
最终用户对项目的接受程度 |
用户完全接受系统的概念和细节，认为处理流程是适合需求的 |
用户接受系统的大部分概念和细节，认为处理流程是适合需求的 |
最终用户拒绝接受系统的概念和设计细节 |
|
| 15 |
最终用户的培训需求 |
培训需求已被充分考虑，培训工作正在进行或已有合适的计划 |
培训需求已被充分考虑，但培训工作没有开始并且没有合适的计划 |
培训需求没有被考虑过 |
|
| 16 |
最终用户在项目涉及的领域中的知识 |
最终用户对项目涉及的领域有相当的知识和经验 |
该领域对最终用户相对较新，但已经开始对他们进行适当的培训 |
用户对该领域几乎没有任何认识，并且没有计划好的培训工作 |
|
| 17 |
最终用户之间的相似程度 |
绝大多数用户有着相同的背景，并且会用相同的方式使用本系统 |
用户将使用一些已经定义好的流程使用系统 |
用户使用本系统的流程可能是多种多样的 |
|
| |
客户的技术部门 |
|
|
|
| 18 |
客户组织吸引和留住员工的能力 |
客户能够招聘到并且留住有足够技能的员工，并对技能不足的员工进行适当的培训 |
客户能够招聘到有限数量的有足够技能的员工，可能需要支付额外的奖金 |
很少人愿意在客户的组织中工作，客户也因为员工的频繁流失而不愿意对他们进行培训 |
|
| 19 |
人力资源管理经验 |
客户在人力资源的管理和发展上有很强的经验 |
客户在人力资源的有效管理上有成功和失败的记录 |
客户没有能力保留住好的员工和管理人员 |
|
| 20 |
临时员工的雇佣 |
客户仅仅偶尔雇佣临时员工作为固定员工的补充 |
客户有一些临时员工，主要目的是传授技能给固定员工 |
客户组织中有大量的临时员工，并且几乎没有技能转移的工作 |
|
| |
|
|
|
|
|
| |
项目角度的要素和分类 |
|
| |
|
|
|
|
|
| |
项目特征 |
|
|
|
|
| 21 |
项目复杂度 |
项目较小，不很复杂，或很容易分解 |
项目规模中等，复杂度中等，可以被分解 |
大型项目，高复杂度，难于分解 |
|
| 22 |
硬件限制 |
几乎没有硬件限制，单一系统平台 |
有一些硬件限制；少量几个平台 |
重大的硬件限制，多平台系统 |
|
| 23 |
需求稳定性 |
对定义好的需求基本不会发生变化 |
基本需求可能会发生一些变化 |
没有基本需求，或基本需求变化很快 |
|
| 24 |
需求的完备性和清晰度 |
所有需求都被定义完全且记录清晰 |
某些需求未完成或尚不清楚 |
有某些需求只有客户自己知道 |
|
| 25 |
客户期望值 |
客户期望值与项目组相同 |
双方没有正式讨论过项目的期望值，但看起来是相同的 |
客户的期望值与项目组不同 |
|
| 26 |
项目完成的标准 |
双方完成的标准是一致的 |
完成标准没有正式讨论过 |
项目组和客户之间在完成项目的标准上有争议 |
|
| 27 |
成本/收益计算 |
成本/收益计算已经精确可靠地完成 |
成本/收益计算完成，遗留一些适用性问题 |
对系统的成本/收益没有满意的计算，预算与项目计划脱节 |
|
| 28 |
可测试性 |
项目需求很容易被测试，测试计划正在进行中 |
项目的某些部分很难被测试，或测试计划刚刚开始制定了一小部分 |
项目的大部分都难于测试，或项目测试计划尚未开始制定 |
|
| 29 |
项目是否适合企业架构 |
项目的实施与企业架构的所有部分都很符合 |
企业架构的某些部分未定义，或与项目的要求有差别 |
企业架构尚未建立，或该架构与项目实施的要求冲突 |
|
| 30 |
设计难度 |
项目的设计良好，有完备的接口，且设计文档易于理解 |
设计方法还不很清楚，或某些方面有待于决定 |
接口混乱，难于控制，目标还在变化 |
|
| 31 |
实现难度（复杂度） |
算法和设计合理，易于实现 |
算法和设计的某些方面对项目组有一些难度 |
项目组发现算法和设计中包含有很难实现的组件 |
|
| 32 |
系统关联性 |
系统的软件部分和系统其他部分（如硬件、处理流程、文档）的依赖关系的说明很清晰 |
系统的某些部分计划很好，易于理解，但其他部分则难于理解 |
关于整个系统的整合，没有清晰的计划或进度表 |
|
| 33 |
可重用组件 |
组件已经可用，且与处理流程兼容 |
组件应该可用，但发布日期未定 |
组件在项目计划中，但需要时却不可用 |
|
| 34 |
替代组件 |
组件可以被直接使用 |
组件在绝大多数环境下可用 |
组件在一定的条件下会失败，或组件的发布会推迟，或组件与某些处理流程不兼容 |
|
| |
项目的决定 |
|
|
|
|
| 35 |
行政因素的影响 |
所有决定都不是由行政影响而作出的 |
项目中的某些决定不是因为技术或管理的原因，而是行政上的需要 |
项目中的大多数决定都是行政上的原因，而没有技术或管理上的因素 |
|
| 36 |
确定项目结束日期 |
发布日期是基于项目组对项目进展的估计作出的 |
发布时间的确定部分由于市场的需要或其他方面的因素 |
发布日期的确定完全是由于市场的需要，或财务目标，或其他类似因素，却没有考虑到项目组对工作时间的估计 |
|
| 37 |
开发技术的选择 |
技术选择完全符合客户的需求 |
之所以选择某种新技术，部分是由于新技术本身 |
项目成了引进新技术的借口，而新的技术对满足用户需求毫无用处 |
|
| 38 |
短期的解决方案 |
项目可以满足短期的需求，又不影响长期的规划 |
项目的解决方案只注重于解决目前的问题，而对长期的需求考虑较少 |
解决方案完全是为了能够完成短期的任务，而全然不顾项目的远景规划 |
|
| |
项目的开发过程 |
|
|
|
| 39 |
项目的依赖性 |
所有的依赖因素都是已知的，并且有可靠的保证 |
某些依赖条件可能会部分导致延期 |
影响项目的条件是员工、决策或组件不足 |
|
| 135 |
评估流程 |
有良好而规范的流程来评估工作量、费用和工作成绩 |
评估的过程是不正式的，但结果代表了大多数人的意见 |
根本不做评估，或评估基于个人的、非正式的推测 |
|
| 40 |
对评估结果的信任度 |
任务划分明确，项目组对评估结果高度信任 |
项目组成员对评估结果的某些部分缺乏信任 |
任务划分不明，评估涉及的范围太广，或项目组不信任评估结果 |
|
| 41 |
可选方案的分析 |
对可选方案的考虑完全而彻底，假设条件正确 |
对可选方案的分析彻底，但假设条件有问题；或不是所有可能方案都被考虑到 |
分析不完全，某些方案没有被考虑；或假设条件错误 |
|
| 42 |
现有系统的文档 |
现有系统的文档完全，格式通用统一，项目组很容易理解且从中获益 |
部分系统有文档说明；每一部分文档有自己的编写方法 |
没有有关现有系统的文档；或现有文档不正确或已过期 |
|
| 43 |
改变决议的流程 |
有关目标、内容和时间进度表的改变由所有人讨论并通过 |
决议的改变与所有人交流过 |
没有经过所有人的讨论就改变决议的内容 |
|
| 44 |
保证各种流程的实施 |
处理各种事件的流程是适当而有效的，并被项目组严格遵守，从而使得项目能够顺利实施 |
项目组有处理各种事件的流程，但没有被严格遵守 |
没有可以保证项目顺利进行的流程可供遵守 |
|
| 46 |
项目文档 |
文档正确可用，由项目组成员在项目进展过程中编写 |
缺少部分文档，但已有文档是可用的，可能滞后于项目进展 |
没有项目文档；没有建立项目内部文档的计划 |
|
| 47 |
开发流程的制订和使用 |
项目进展流程已经建立，并且是适当的和高效的，项目组成员遵照该流程工作 |
流程已建立，但效果不好，没有被很好的遵守 |
没有正式的工作流程 |
|
| 48 |
及早发现缺陷 |
开发组成员一直坚持对项目的各个部分作检查 |
开发组偶尔对项目作检查 |
开发组希望由测试人员去发现所有的错误 |
|
| 49 |
缺陷跟踪 |
缺陷跟踪的方法明确且有效，并一直使用 |
规定了缺陷跟踪的方法，但没有坚持使用 |
没有规定缺陷跟踪的方法 |
|
| 50 |
更新控制 |
有有效的正式的更新控制流程，且一直被遵守 |
存在更新控制流程，但效果不好或未被遵守 |
没有使用任何更新控制流程 |
|
| |
|
|
|
|
|
| |
|
|
|
|
|
| |
项目开发和部署的环境 |
|
|
|
| 52 |
物理设备 |
几乎不需要改变 |
某些已存在，其他需要改变 |
需要较大的改造 |
|
| 53 |
硬件平台 |
平台稳定，有足够的能力，不需要改变 |
平台有一些变化，但在控制之下 |
平台与软件在开发中 |
|
| 54 |
工具可用性 |
有效的，合适的，有文档 |
可用的，有效的，但需要一些二次开发或几乎没有文档 |
没有用处；或有版权问题；或需要大量的二次开发；没有任何文档 |
|
| 55 |
其他开发商的支持 |
在需要的时候有完全的支持，且价格合理 |
在合理的响应时间内有足够的支持，且价格已经签约 |
几乎没有支持，价格太高，响应时间长 |
|
| 56 |
灾难恢复 |
所有领域都遵守安全准则；数据备份工作完好；有合适的灾难恢复系统；所有工作都遵循以上准则 |
有一些安全措施；有备份数据；灾难恢复已被考虑，但缺乏有效的手段或这些措施没有被完全遵守 |
没有合适的安全措施；缺少备份机制；没有考虑灾难恢复 |
|
| |
项目（程序）管理 |
|
|
|
| 57 |
管理方法 |
具有有效的计划和监督的机制和工具 |
计划和监督机制需要加强 |
几乎没有计划和监督机制 |
|
| 58 |
管理经验 |
项目经理和程序经理在类似项目上很有经验 |
项目经理和程序经理在类似项目上有一些经验，或在其它项目上有管理经验 |
项目经理和程序经理没有经历过类似项目的管理工作，或在项目管理上是新手 |
|
| 59 |
项目和程序经理的权威 |
具有管理上的或官方的权威，可以有效的承担领导项目组的任务 |
基于私人的关系，可以影响组织中的其他成员 |
既没有官方的地位也没有个人的影响，从而在做出决定和资源调配上没有影响力 |
|
| 60 |
来自项目组的支持 |
受到项目组和管理层的完全支持 |
项目组中有些人持保留态度，但大多数人表示支持 |
几乎得不到支持，只有名义上的管理权 |
|
| 61 |
确定项目标准 |
对于项目的开发，实施和维护，在项目计划中都有标准的程序、方法和工具 |
项目计划中确定了一部分标准的程序、方法和工具 |
项目计划中没有涉及到项目需要使用的程序、方法和工具 |
|
| 62 |
交付系统所需的硬件资源 |
系统足够成熟和灵活，且有可扩展的能力 |
硬件系统可用，有一些扩展能力 |
没有扩展能力，不灵活 |
|
| 63 |
响应能力和其他性能上的要素 |
已经准备好适应各种情况，已经做过很好的分析 |
偶尔需要应付极端情况 |
在实际操作中总是在满负荷运转 |
|
| 79 |
对用户支持服务的影响 |
几乎不需要改变用户支持服务 |
用户支持服务需要很少量的变化 |
需要对用户支持服务作较大的变化；或需要该部门提供更多的支持 |
|
| 80 |
数据迁移的需求 |
几乎不需要数据迁移 |
需要大量的数据迁移，但对该过程有清晰的描述，且有明确的迁移方案 |
大量的数据需要迁移，有些数据库系统的迁移没有清晰的描述和详细的文档 |
|
| 81 |
外部的软硬件接口 |
几乎不需要与外部的接口集成，或不需要向外界提供接口 |
需要作一些集成或接口工作 |
需要作大量的接口工作 |
|
| 136 |
跟踪项目的成绩和成本 |
已经对项目的成绩和成本进行了有效的跟踪，并在他们超出计划范围时作出了有效的努力 |
已经对项目的成本进行了正式的跟踪，并通常在需要时会有正确的动作 |
没有对项目的成本进行跟踪，除非是发现了很大的偏差 |
|
| |
项目组 |
|
|
|
|
| 61 |
项目组成员的可用性 |
总是就绪，几乎没有什么原因可以导致中断工作 |
基本可用，有时候会因紧急事件而中断工作 |
几乎不可用，成员花费大量的时间用于应付紧急事件 |
|
| 62 |
综合技能 |
综合技能极好 |
某些技能不是很充分 |
不具备某些必要的技能 |
|
| 63 |
项目组是否覆盖了msf的所有角色 |
所有角色都具备 |
客户需要扮演其中的几个角色 |
关键性的角色缺乏 |
|
| 64 |
类似项目的经验 |
项目组在类似项目上有大量的经验 |
在类似项目中有一定经验 |
几乎没有类似项目的经验 |
|
| 66 |
开发流程的经验 |
在这种流程上有大量的经验 |
在这种流程上有一些经验或在其他流程上有大量的经验 |
没有正规流程的经验 |
|
| 67 |
项目状态的交流 |
项目组成员之间以及项目组与组外人员之间在项目目标和状态上有良好的交流 |
项目组有时候在某些信息上有交流 |
项目组几乎不同那些需要明了项目状态的人员进行交流 |
|
| 68 |
m项目组的培训 |
有合适的培训计划，且计划在执行中 |
某些领域没有培训，或计划在将来培训 |
没有任何培训计划，或培训工作尚未准备好 |
|
| 69 |
项目组成员的精神状态 |
对项目的成功有强烈的愿望，合作精神好 |
愿意做好自己的工作 |
没有一个凝聚力好的项目组，成员没有做好项目的愿望 |
|
| 70 |
项目组的工作效率 |
工作效率很高，达到了所有的里程碑，按时完成所有工作 |
工作效率较好，某些工作有延时，达到了里程碑的要求 |
工作效率低，工作延时，没有达到里程碑的要求 |
|
| 71 |
项目领域的专业技术 |
开发组成员在项目涉及的领域有很好的背景知识 |
在该领域有一些专业知识，或在需要时有专家的支持 |
项目组成员在该领域没有专业支持，且没有专家的支持 |
|
| |
|
|
|
|
|
| |
项目技术 |
|
|
|
|
| 73 |
技术与项目的符合程度 |
对客户的问题，项目所采用的技术有可靠的解决方案 |
项目计划中采用的技术对解决客户的问题在某些方面不是很合适 |
所选择的技术与解决客户的问题之间有较大的差异 |
|
| 74 |
与工业标准的符合程度 |
技术路线符合客户的组织体系和技术架构 |
技术路线对用户是全新的，但是与现存的标准和技术架构没有冲突 |
技术路线与现有的标准或技术架构有矛盾，或没有成文的标准 |
|
| 75 |
技术专家的可用性 |
有可用的技术专家 |
在机构中有可用的专家，但不在项目组之内 |
需要在机构外寻找帮助 |
|
| 76 |
技术成熟性 |
该技术已经使用了很长时间 |
技术被项目组充分理解 |
采用的是可能导致失败的新技术 |
|
| |
项目维护 |
|
|
|
|
| 82 |
设计复杂性 |
高可维护性 |
某些方面难于维护 |
非常难于维护 |
|
| 83 |
维护人员 |
有足够的合适的有经验的人员 |
缺少某些方面的专家 |
非常缺乏受过训练的专家 |
|
| 84 |
其他开发商的支持 |
在需要的时候有完全的支持，且价格合理 |
在合理的响应时间内有足够的支持，且价格已经签约 |
几乎没有支持，价格太高，响应时间长 |
|
| 85 |
对发行版本的支持 |
客户或合作伙伴被完全包含在项目中，他们承担起完全的支持发行版本的责任 |
客户或合作伙伴愿意承担支持发行版本的责任，但缺乏足够的能力 |
不愿意承担责任，或不认为该工作很重要 |
|
| |
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
