CMMI培训讲义(风险库)fxz.pptx

《CMMI培训讲义(风险库)fxz.pptx》由会员分享，可在线阅读，更多相关《CMMI培训讲义(风险库)fxz.pptx（15页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、CMMI CMMI 培培 训训 讲讲 义义风险库风险库讲讲 师：王师：王 龙龙 2009 2009年年0808月月1111日日商业风险风险类型检查项风险的原因阈值发生的阶段风险缓解措施政治法律市场政府或者其他机构对本项目的开发有限制法律法规的变化9立项立项时加强立项调查,需求分析可能有不可预测的市场动荡法律法规的变化9立项立项时加强立项调查,需求分析可能有不利于我方的官司要打合同等不正规;法律法规的变化9立项立项时加强立项调查,需求分析本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故无客户服务9立项立项时加强立项调查,需求分析竞争对手可能会有不正当的竞争行为竞争对手的素养9立项立项时加

2、强立项调查,需求分析在开发很少有人真正需要却自以为很好的产品公司的发展战略9立项立项时加强立项调查,需求分析可能在开发可能亏本的产品公司的发展战略;公司的开发能力9立项立项时加强立项调查,需求分析商业风险风险类型检查项风险的原因阈值发生的阶段风险缓解措施客户客户的需求含糊不清客户的联系人自己不明白;需求调查不清楚9需求开发安排充分时间的需求调查,需求文档用户要有承诺客户反反复复地改动需求客户的联系人自己不明白;需求调查不清楚;客户没有承诺;9需求开发安排充分时间的需求调查,需求文档用户要有承诺客户指定的需求和交付期限在客观上不可行客户不了解开发;公司的开发能力低于产品需求的开发能力9需求开发安

3、排充分时间的需求调查,需求文档用户要有承诺,重新变更合同客户对产品的健壮性、可靠性、性能等质量因素有非常过分的要求客户要求高9需求开发安排高水平的项目组,需求文档用户要有承诺客户的合作态度不友善客户与我们的公司关系不好.客户代表与客户公司之间与问题.9需求开发需求文档用户要有承诺与客户签订的合同不一定公正.不一定双方互利.合同不公正,不正规,有法律漏洞9立项签订合同时应有法律顾问来审查,有必要时应修改合同,需求文档用户要有承诺按客户的需求开发了产品，但是客户可能不购买。客户是信誉不好9测试验收需求文档用户要有承诺,法律解决商业风险风险类型检查项风险的原因阈值发生的阶段风险缓解措施供应商与供应商

4、签订的合同不一定公正.不一定双方互利.合同不公正,不正规,有法律漏洞9采购签订合同时应有法律顾问来审查供应商的信誉不好供应商信誉不好,没有执行正确的供应商选择过程9采购重新执行正确的选择供应商的过程供应商有可能倒闭供应商产品不好,市场不好.经营差,金融危机,经济危机,没有执行正确的供应商选择过程9采购重新执行正确的选择供应商的过程供应商不能及时交付质量合格的产品(或部件)供应商的生产能力弱,跟踪差9采购加强跟踪,有可能的话换一个新的供应商供应商没有能力做好售后服务供应商的售后服务能力差9采购在采购初期执行正确的选择供应商的过程管理风险风险类型检查项风险的原因阈值发生的阶段风险缓解措施项目计划对

5、项目的规模、难度估计可能不太正确准确项目估算能力差,工作不够,估算方法不对.估算的参考信息少9项目策划增加估算力度,运用合理的方法人力资源(开发人员,管理人员)不够用不合格.公司人员不足,人员水平低9项目策划申请人员项目所需的软件、硬件不能按时到位采购部门不能按时采购,所需软硬件无法买到.供方出现偏差9项目策划跟踪采购,执行正确的采购确定方案过程项目的经费不足客户预付款没有到帐.公司帐务管理问题.项目浪费9项目策划增加估算力度,运用合理的方法,加强费用管理进度安排可能过于紧张,没有合理的缓冲时间工期短.估算不足9项目策划增加估算力度,运用合理的方法进度表中可能遗忘了一些重要的(必要的)任务估算

6、不足,需求调查不够9项目策划增加估算力度,运用合理的方法进度安排没有考虑了关键路径估算与策划不足9项目策划增加估算力度,运用合理的方法可能出现某一项工作延误导致其他一连串的工作也被延误没有考虑关键路径,估计不足9项目策划增加估算力度,运用合理的方法任务分配不合理,任务没有分配给合适的项目成员估算与策划不足9项目策划重新估算,重新策划,把任务分配给合适的项目成员充分发挥其才能为了节省钱,不采用(购买)成熟的软件模块,一切从零做起项目利润低,工期有富余.9项目策划加强决策分析的过程能者多劳,任务分配不平衡估算与策划不足9项目策划合理分配工作与任务,建立好的奖励机制管理风险风险类型检查项风险的原因阈

7、值发生的阶段风险缓解措施项目团队项目成员不团结,存在矛盾员工之间有过节,员工的信仰不同9整个过程多开展娱乐活动,促进交流部分的项目成员对工作不认真负责公司福利不好,客户关系不好,员工素质差,工作环境差9整个过程多开展娱乐活动,促进交流,建立好的奖励机制,部分的项目成员工作热情不高公司福利不好,客户关系不好,员工素质差,工作环境差9整个过程多开展娱乐活动,促进交流,建立好的奖励机制,团队之中可能有“害群之马”员工素质差,技术水平低.员工想离职公司却不放人.9整个过程多开展娱乐活动,促进交流,建立好的奖励机制与惩罚机制技术开发队伍中有临时工公司人员不足,人员水平低,有临时人员需求9整个过程公司建立

8、临时人员的管理机制,安全措施.对临时人员建立合理的风险控制能力本项目开发过程中可能会有核心人员辞职、调动本项目的级别低,核心人员不想加入这个项目,核心人员在加入项目之前就想辞职了.9整个过程公司人员储备不能保证人员流动基本不会影响工作的连续性相应职务与级别的员工比较缺少9整个过程建立合理有效的工作记录,加强人才储备项目经理忙于行政事务无暇顾及项目的开发工作项目的干系人总是影响项目,项目经理身兼多职.项目组内成员复杂,水平素质参差不齐9整个过程项目经理专职,策划时规范干系人活动并得到承诺.策划时合理安排人员.管理风险风险类型检查项风险的原因阈值发生的阶段风险缓解措施上级领导行政部门合作部门上级领

9、导可能随时会抽调本项目的资源用于其他高优先级的项目项目计划时没有承诺,项目工期不紧张.客户要求不高,资源确定时没有考虑.9整个过程保证完整的项目承诺,安排项目工期时应有一定的保证.向上级申请项目延期,上级领导不是很重视本项目项目利润不高,规模小,成熟项目9整个过程找领导谈话,汇报工作上级领导会过多地介入本项目的事务并且瞎指挥项目计划时没有承诺,领导能力差,项目经理能力差9整个过程建立承诺行政部门的办事效率比较低以至于拖项目的后腿行政部门的配合力度不够,项目计划时没有承诺,高层控制不力9整个过程协调,必要时向更高级领导反映情况行政部门可能会干一些无益于生产力的事情,以至于骚扰本项目行政部门的配合

10、力度不够,项目计划时没有承诺,高层控制不力9整个过程协调,必要时向更高级领导反映情况公司不能全面公正地考核员工的工作业绩考核方法与奖惩办法不力9整个过程多开展娱乐活动,促进交流,建立好的奖励机制与惩罚机制机构没有较好的奖励和惩罚措施考核方法与奖惩办法不力9整个过程多开展娱乐活动,促进交流,建立好的奖励机制与惩罚机制本项目的合作部门的态度不积极,应付了事,或者做事与承诺的不一致各部门的配合力度不够,项目计划时没有承诺,高层控制不力,项目经理能力不足,与人交恶9整个过程多开展娱乐活动,促进交流,建立好的奖励机制与惩罚机制技术风险风险类型检查项风险的原因阈值发生的阶段风险缓解措施需求开发需求管理需求

11、开发人员不懂得如何获取用户需求无真正的需求开发人员9需求开发立项时申请专业的需求开发人员或系统分析师需求开发效率不高客户对需求不清.开发人员能力不足,客串的或临时的需求开发人员9需求开发立项时申请专业的需求开发人员或系统分析师需求开发人员不懂项目所涉及的具体业务.不能否理解用户的需求开发人员能力不足,无真正的需求开发人员,客串的或临时的需求开发人员9需求开发立项时申请专业的需求开发人员或系统分析师需求文档不能够正确地、完备地表达用户需求开发人员能力不足,无真正的需求开发人员,客串的或临时的需求开发人员,需求开发人员文案能力低下,文档模板不好,9需求开发立项时申请专业的需求开发人员或系统分析师需

12、求开发人员不能与客户对有争议的需求达成共识需求开发人员不懂项目所涉及的具体业务,需求开发人员职责权限有限9需求开发立项时申请专业的需求开发人员或系统分析师,项目经理参与需求开发需求开发人员不能获得客户对需求文档的承诺,不能保证客户不随便变更需求客户素质差,客户与项目组关系不好,项目经理或需求开发人员与客户交恶9需求开发立项时申请专业的需求开发人员或系统分析师,项目经理参与需求开发,项目经理增加与客户的交流技术风险风险类型检查项风险的原因阈值发生的阶段风险缓解措施综合技术开发能力包括设计测试等开发人员没有相似产品的开发经验公司人力不足,使用实习人员,人员搭配不合理9策划-开发立项或项目策划时申请

13、有能力的人员,加强培训待开发的产品可能要与未曾证实的软硬件相连接采购部门更改采购内容,客户提供的资源有变化,集成测试不力,估算与策划不力9开发编码按正确的过程确定采购方案,集成方案,提前采购,加强对软硬件的培训.对开发人员而言,本项目的技术难度高公司人力不足,人员搭配不合理,项目是公司业务拓展试点9策划-开发培训,申请人员开发人员没有全部掌握了本项目的关键技术培训不足.9策划-开发培训,申请人员如果某项技术尚未实践过,开发人员不能在预定时间内掌握技术难度大,开发人员学习能力差,培训差.9策划-开发增加前期培训,申请人员开发小组没有采用比较有效的分析、设计、编程、测试工具估计与策划不力,开发小组

14、水平低9策划-开发加强估算策划设计.增加培训分析与设计工作过于简单、草率，从而让程序员边做边改需求开发人员工作热情不高.工期短,分析与设计与开发是同一人完成9策划-开发划分合理的工作任务安排,确定职责与权限,合理的里程碑开发小组没有采用统一的编程规范公司无规范,开发小级无QA,无评审活动,项目经理管理不力9开发制定编程规范,申请QA,加强评审.开发人员对测试工作不重视,不能保证测试的客观性公司不重视测试工作,无专门的测试人员,产品质量与工资无关9测试验收建立奖惩制定,产品质量与效益挂勾项目经理对测试工作不重视公司不重视测试工作,无专门的测试人员,产品质量与工资无关9测试验收建立奖惩制定,产品质

15、量与效益挂勾客户对测试工作没有要求客户认为公司的质量要求能满足他们的要求.客户对开发工作不了解9测试验收不管有没有,都要有测试过程项目没有独立的测试人员,不懂得如何进行高效率地测试公司不重视测试工作,无专门的测试人员,产品质量与工资无关9测试验收增加测试人员的策划没有对所有重要的工作成果进行了同行评审(正式评审或快速检查)工期短.重视不足,人员少9整个过程增加测试人员的策划开发人员不懂得版本控制和变更控制,不能够按照配置管理规范执行无配置管理员9开发加强策划与培训,安排配置管理人员开发人员不重视质量,会在进度延误时降低质量要求公司不重视测试工作,无专门的测试人员,产品质量与工资无关9开发加强策

16、划与培训风险等级风险等级严重性严重性等级等级等级说明等级说明举例说明举例说明0 0灾难性的系统报废/项目破产/人员死亡1 1严重的项目延期过大,成本超支超过50%2 2轻度的项目轻度延期,成本超支不大在1K至2K之间3 3轻微的成本超支不大在1K以内可能性等级可能性等级等级等级等级说明等级说明个体发生情况个体发生情况总体发生情况总体发生情况0 0频繁频繁发生连续发生1 1很可能在寿命期内会出现若干次频繁发生2 2有时在寿命期内可能有时发生发生若干次3 3极少在寿命期内不易发生，但有可能发生不易发生，但有理由可预期发生4 4不可能很不容易发生，以至于可以认为不会发生不易发生，但有可能发生优先级优

17、先级 严重性严重性可能可能性性0(灾灾难难的的)1(严严重的重的)2(轻轻度的度的)3(轻轻微的微的)0(频频繁繁)137131(很可能很可能)259162(有有时时)4611183(极少极少)81014194(不可能不可能)12151720说明：说明：15：为不可接受的风险，必须尽量避免其发生。69：为不希望有的风险，需要定出决策避免发生，或降低危害。1017：是可控制的、可接受的风险，需要对风险评审后决定是否管理它。1820是不经评审即可接受的风险。此类风险可以不予管理。本分数划分的原则是严重性的等级高于可能性。注：先判断风险的严重性和可能性等级，然后再根据优先级表中的数据计算出风险的优先级。谢谢 谢！谢！演讲完毕，谢谢观看！