免费查个人风险报告,软件风险管理标准化方案、风险检查表、风险管理报告

本表灰色部分的风险系数值为10~25，应当优先处理。

表7-3 风险系数等级

风险严重性的等级划分如表7-1所示，风险可能性的等级划分如表7-2所示，风险系数的等级划分如表3所示。

风险管理有4个主要活动：

◆风险识别：根据风险检查表，识别出本项目的风险。

◆风险分析：估计风险严重性、风险可能性、风险系数。

◆风险减缓：对于风险系数超过“容许值”的每一个风险，都应当采取减缓措施。

◆风险跟踪：跟踪风险减缓过程，记录风险的状态。

图7-1 风险管理示意图

在项目的生命周期内，上述4个活动将被循环执行，如图7-1所示。直到项目的所有风险都被识别与解决为止。

常用的风险检查表见 [SPP-TEMP-RISKM-CHECKLIST]，使用者应根据实际情况进行适当的删减或补充。风险管理过程域产生的主要文档是《风险管理报告》，模板见 [SPP-TEMP-RISKM-REPORT]。

在项目的生命周期内，循环执行风险识别、风险分析、风险减缓和风险跟踪，直到项目的所有风险都被识别与解决为止。

项目经理负责风险管理。

项目成员协助项目经理处理风险。

《项目计划》已经制定，项目研发已经开始。

《项目计划》

项目监控过程产生的文档如《项目监控数据表》、《项目偏差控制报告》和《项目进展报告》等

项目经理根据“风险检查表”[SPP-TEMP-RISKM-CHECKLIST]，定期（例如每周一次）识别本项目的风险。

项目经理评估每个风险的严重性、可能性和风险系数，并按照风险系数从高到低的顺序排列风险。

对于风险系数超过“容许值”（建议为10）的每一个风险，项目经理应当给出风险减缓措施，并指定责任人。风险系数越高，越先处理。

项目经理跟踪风险减缓过程，直到风险已经解决为止。如果风险的性质发生变化，应当及时更新风险减缓措施

《风险管理报告》

所有风险都已经解决，相关信息已经记录到《风险管理报告》之中。

项目经理统计工作量。

对风险管理过程域产生的所有有价值的文档进行配置管理。

项目经理根据本项目的特征，确定风险识别的频度（通常为每周一次），适当修改“风险检查表”[SPP-TEMP-RISKM-CHECKLIST]。

选用合适的软件工具，尽量减少风险管理过程域的工作量。

项目监控和风险管理均由项目经理负责，建议同步执行。

附录一：《风险检查表》

商业风险

风险类型

检查项

政治

法律

市场

政府或者其他机构对本项目的开发有限制吗？

有不可预测的市场动荡吗？

有不利于我方的官司要打吗？

本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗？

竞争对手有不正当的竞争行为吗？

本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗？

是否在开发很少有人真正需要却自以为很好的产品？

是否在开发可能亏本的产品？

客户

客户的需求是否含糊不清？

客户是否反反复复地改动需求？

客户指定的需求和交付期限在客观上可行吗？

客户对产品的健壮性、可靠性、性能等质量因素有非常过分的要求吗？

客户的合作态度友善吗？

与客户签的合同公正吗？双方互利吗？

客户的信誉好吗？例如按客户的需求开发了产品，但是客户可能不购买。

子承包商

供应商

与子承包商、供应商签订的合同公正吗？双方互利吗？

子承包商、供应商的信誉好吗？

子承包商、供应商有可能倒闭吗？

子承包商、供应商能及时交付质量合格的产品（或部件）吗？

子承包商、供应商有能力做好售后服务吗？

管理风险

风险类型

检查项

项目计划

对项目的规模、难度估计是否比较正确？

人力资源（开发人员、管理人员）够用吗？合格吗？

项目所需的软件、硬件能按时到位吗？

项目的经费够用吗？

进度安排是否过于紧张？有合理的缓冲时间吗？

进度表中是否遗忘了一些重要的（必要的）任务？

进度安排是否考虑了关键路径？

是否可能出现某一项工作延误导致其他一连串的工作也被延误？

任务分配是否合理？（即把任务分配给合适的项目成员，充分发挥其才能）

是否为了节省钱，不采用（购买）成熟的软件模块，一切从零做起？

…

项目团队

项目成员团结吗？是否存在矛盾？

是否绝大部分的项目成员对工作认真负责？

绝大部分的项目成员有工作热情吗？

团队之中有“害群之马”吗？

技术开发队伍中有临时工吗？

本项目开发过程中是否会有核心人员辞职、调动？

是否能保证“人员流动基本不会影响工作的连续性”？

项目经理是否忙于行政事务而无暇顾及项目的开发工作？

上级领导

行政部门

合作部门

本项目是否得到上级领导的重视？

上级领导是否随时会抽调本项目的资源用于其他“高优先级”的项目？

上级领导是否过多地介入本项目的事务并且瞎指挥？

行政部门的办事效率是否比较底，以至于拖项目的后腿？

行政部门是否经常干一些无益于生产力的事情，以至于骚扰本项目？

机构是否能全面、公正地考核员工的工作业绩？

机构是否有较好的奖励和惩罚措施？

本项目的合作部门的态度积极吗？是否应付了事？或者做事与承诺的不一致？

技术风险

风险类型

检查项

需求开发

需求管理

需求开发人员懂得如何获取用户需求吗？效率高吗？

需求开发人员懂得项目所涉及的具体业务吗？能否理解用户的需求？

需求文档能够正确地、完备地表达用户需求吗？

需求开发人员能否与客户对有争议的需求达成共识？

需求开发人员能否获得客户对需求文档的承诺？以保证客户不随便变更需求？

综合技术

开发能力

包括设计

编程、测试等

开发人员是否有开发相似产品的经验？

待开发的产品是否要与未曾证实的软硬件相连接？

对开发人员而言，本项目的技术难度高吗？

开发人员是否已经掌握了本项目的关键技术？

如果某项技术尚未实践过，开发人员能否在预定时间内掌握？

开发小组是否采用比较有效的分析、设计、编程、测试工具？

分析与设计工作是否过于简单、草率，从而让程序员边做边改？

开发小组采用统一的编程规范吗？

开发人员对测试工作重视吗？能保证测试的客观性吗？

项目有独立的测试人员吗？懂得如何进行高效率地测试吗？

是否对所有重要的工作成果进行了同行评审（正式评审或快速检查）？

开发人员懂得版本控制、变更控制吗？能够按照配置管理规范执行吗？

开发人员重视质量吗？是否会在进度延误时降低质量要求？

附录二：《风险管理报告》

风险名称

风险识别人

风险编号

风险识别日期

风险描述

风险严重性

风险系数

风险可能性

风险处理人

风险减缓措施

跟踪记录

（1）记录何人在何时做了什么事情

（2）记录当前风险状态（正在处理，已经解决，不作处理）