CMMI风险管理说明及相关文档模板

第7章风险管理介绍TOC\o"1-5"\h\z风险管理规程2目的2角色与职责3启动准则3输入3主要步骤3[Stepl]风险识别3[Step2]风险分析3[Step3]风险减缓3[Step4]风险跟踪3输出4结束准则4度量4实施建议4风险管理(RiskManagement,RiskM)的Fl的是在风险产生危害之前识别它们，从而有计划地消除或削弱风险。风险管理过程域是SPP模型的用要组成部分。本规范阐述了风险管理的规程，该规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均己定义。本规范适用于国内IT企业的软件研发项目。建议用户根据自身情况(如商业目标、研发实力等)适当地修改本规范，然后推广使用。7.1介绍所有可能危害项目的因素都称为风险。被刻画为风险的事件最终可能发生也可能不发生.人们对待风险有两种态度。一种是被动态度，可比作“救火模式:另一种是主动态度，可比作“防火模式”。风险管理属于“防火模式”，目的就是“防止风险产生真正的危害”。为了便于量化管理，我们给风险定义3个参数：令风险严重性：指风险对项目造成的危害程度。令风险可能性：指风险发生的几率。令风险系数：是风险严重性和风险可能性的乘积。参数等税值描述风险严重性很高5例如进度延误大丁30%,或者费用超支大丁30%>・比较高4例如进度延误20%~30%,或者费用超支20%~30%.中等3例如进度延误低于20%,或者费用超支低于20%.比较低2例如进度延误低于10%,或者费用超支低于10%.很低1例如进度延误低于5%,或者费用超支低于5%.表7・1风险严重性等级等级1值描述风险可能性很高5风峻发生的几率为比较高4风险发生的几率为中等3风险发生的几率为比较低2风险发生的几率为很低1风险发生的几率为表7-2风险可能件等级风险系数风险可能性很高5比较高4中等3比较低2很低1风险严重性很高5252015105比较高420161284中等31512963比较低2108642很低154321本表灰色部分的风险系数值为1。~25,应当优先处理•表7-3风险系数等级风险严重性的等级划分如表7-1所示，风险可能性的等级划分如表7.2所示，风险系数的等级划分如表3所示。风险管理有4个主要活动：。风险识别：根据风险检查表，识别出本项目的风险。今风险分析：估计风险严重性、风险可能性、风险系数。>风险减缓：对于风险系数超过“容许值”的每一个风险，都应当采取减缓措施。<风险跟踪：跟踪风险减缓过程，记录风险的状态。风险识别「1/S、风险跟踪“5风险分析风险减缓

图7-1风险管理示意图在项目的生命周期内，上述4个活动将被循环执行，如图7-1所示。直到项目的所有风险都被识别与解决为止。常用的风险检查表见[SPP・TEMP・RISKM-CHECKLIST],使用者应根据实际情况进行适当的删减或补充。风险管理过程域产生的主要文档是《风险管理报告》，模板见[SPPTEMPRISKM-REPORT]o7.2风险管理规程目的•在项目的生命周期内，循环执行风险识别、风险分析、风险减缓和风险跟踪，直到项目的所有风险都被识别与解决为止。.2角色与职责项目经理负货风险管理。项目成员协助项目经理处理风险。.3启动准则《项目计划》已经制定，项目研发已经开始。.4输入《项目计划》项目监控过程产生的文档如《项目监控数据表》、《项目偏差控制报告》和《项目进展报告》等.5主要步骤[Stepl]风险识别项目经理根据“风险检充表”[SPP-TEMP・RISKM・CHECKLIST],定期（例如每周一次）识别本项目的风险。[Step2]风险分析项目经理评估每个风险的严一重性、可能性和风险系数，并按照风险系数从高到低的顺序排列风险。[Step3]风险减缓对于风险系数超过“容许值”（建议为10）的每一个风险，项目经理应当给出风险减缓措施，并指定责任人。风险系数越高，越光处理。[Step4]风险跟踪项目经理跟踪风险减缓过程，直到风险已经解决为止。如果风险的性质发生变化,应当及时更新风险减缓措施.6输出・《风险管理报告》.7结束准则•所有风险都已经解决，相关信息已经记录到《风险管理报告》之中。・8度量•项目经理统计工作量。7.3实施建议对风险管理过程域产生的所有行价值的文档进行配置管理。项目经理根据本项目的特征，确定风险识别的频度（通常为每周一次），适当修改“风险检查表”[SPP-TEMP-RISKM・CHECKLIST]。选用合适的软件工具，尽量减少风险管理过程域的工作量。项目监控和风险管理均由项目经理负贵，建议同步执行。风险检查表提示：请使用者根据机构和项目的实际情况完善本检查我。商业风险风险类型检查项政治法律市场政府或者其他机构对本项目的开发有限制吗？有不可预测的市场动荡吗？有不利于我方的官司要打吗？本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗？竞争对手有不正当的竞争行为吗？本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗？是否在开发很少有人真正需要却自以为很好的产品？是否在开发可能亏本的产品？客户客户的需求是否含糊不清？客户是否反反复复地改动需求？客户指定的需求和交付期限在客观上可行吗？客户对产品的健壮性、可靠性、性能等腐量因素有非常过分的要求吗？客户的合作态度友善吗？与客户签的合同公正吗？双方互利吗？客户的信誉好吗？例如按客户的需求开发了产品，但是客户可能不购买。子承包商供应商与子承包商、供应商签订的合同公正吗？双方互利吗？子承包商、供应商的信誉好吗？子承包商、供应商有可能倒闭吗？子承包商、供应商能及时交付质量合格的产品（或部件）吗？子承包商、供应商有能力做好售后服务吗？管理风险风险类型检查项项目计划对项目的规模、难度估计是否比较正确？人力资源（开发人员、管理人员）够用吗？合格吗？项目所需的软件、硬件能按时到位吗？项目的经费够用吗？进度安排是否过于紧张？有合理的缓冲时间吗？进度表中是否遗忘了一些重要的（必要的）任务？进度安排是否考虑了关键路径？是否可能出现某一项工作延误导致其他一连串的工作也被延误？任务分配是否合埋？（即把任务分配给合适的项目成员,允分发挥具才能）是否为了节省钱，不采用（购买）成熟的软件模块，一切从零做起？

•••项目团队项目成员团结吗？是否存在矛盾？是否绝大部分的项目成员对工作认真负责？绝大部分的项目成员有工作热情吗？团队之中有“害群之马”吗？技术开发队伍中有临时工吗？本项目开发过程中是否会有核心人员辞职、调动？是否能保证“人员流动基本不会影响工作的连续性”？项目经理是否忙于行政事务而无暇顾及项目的开发工作？上级领导行玫部门合作部门本项目是否得到上级领导的重视？上级领导是否随时会抽调本项目的资源用于其他“高优先级”的项目？上级领导是否过多地介入本项目的事务并且瞎指挥？行政部门的办事效率是否比较底,以至干拖项目的后腿？行政部门是否经常干一些无益于生产力的事情，以至于喊扰本项目？机构是否能全面、公正地考核员工的工作业绩？机构是否有较好的奖励和惩罚措施？本项目的合作部门的态度积极吗？是否应付了事？或者做事与承诺的不一致？技术风险风险类型检查项需求开发需求管理需求开发人员懂得如何获取用户需求吗？效率高吗？需求开发人员懂得项目所涉及的具体业务吗？能否理解用户的需求？需求文档能够正确地、完备地表达用户需求吗？需求开发人员能否与客户对有争议的需求达成共识？需求开发人员能否获得客户对需求文档的承诺？以保证客户不随便变更需求？综合技术开发能力包括设计编程、测试等开发人员是否有开发相似产品的经验？待开发的产品是否要与未曾证实的软硬件相连接？对开发人员而言，本项目的技术难度高吗？开发人员是否已经掌握了本项目的关键技术？如果某项技术尚未实践过，开发人员能否在预定时间内掌握？开发小组是否采用比较有效的分析、设计、编程、测试工具？分析与设计工作是否过于简单、草率，从而让程序员边做边改？开发小组采用统一的编程规范吗？开发人员对测试工作重视吗？能保证测试的客观性吗？项目有独立的测试人员吗？懂得如何进行高效率地测试吗？是否对所有重要的工作成