P12-CMMI实践解析-决策分析
CMMI详细讲解汇总
第一章过程改进简介1.组织有各种各样的商业目标,组织的商业目标通过组织的过程实现。
2.要想达到有竞争力的水平必须不断改进过程。
3.过程改进活动关注改进过程的能力和组织的成熟度来推动组织的发展和实现目标。
4.过程改进活动能提供指导,帮助组织定义和标准化过程、提高工作效率、减少返工、度量组织的性能和利用数据来管理业务。
5.过程改进保证了能给组织带来可度量的收益,特别是在工作量估计和高质量产品的交付能力上。
6.基于模型的过程指的是使用一个模型来指导一个组织的过程改进。
7.一般而言,基于模型的过程改进开始于管理的承诺和评估。
评估的结果又被作为制订下一步行动计划的基础,在完成了这些计划后,再进行进一步的评估,依次下去,其目标是使组织成熟,让它持续地监控和改进过程,一直生产高质量的产品,在市场竞争中游刃有余,并随时进行自我调整来满足客户的需求。
8.工程系统复杂性日益增长、并行工程和交叉学科需要采用集成过程。
9.集成过程改进的真正效益:➢成本改善●采用多种模型和多种方法所需的培训费用。
●在相同的组织中(可能对相同的实践人员)执行多种评估需要的费用。
●在数据仓库中维护冗余的过程资产。
●维护或采购多种模型中的专业知识。
由集成过程改进带来的更多成功机会,较高质量、更好的可预测性以及其他各种改进过程的效益都会使组织实现成本节省。
➢重点明确一个集成过程改进计划可以弄清楚组织各种活动的目的和商业目标。
通过跨越更大范围的学科的各种过程改进活动的集成,就更容易把同时包括实践人员和主管的队伍团结在过程改进的大旗下。
➢过程集成和精益组织集成过程改进的一个不太明显的收益是它对组织产生的“集成”影响。
当过程的定义跨越了组织和学科的边界时,通常会产生新的理解相互学习,从而使关键工作流简化,并消除冗余的或不必要的活动。
➢灵活性与新学科的扩展集成所带来的最后一个效益,是当业务或工程环境发生变化时,具备了增加新学科的能力。
10.集成化过程改进的原则➢强调高层管理人员的支持➢仔细确定目标➢选用最佳实践➢过程改进要与业务目标一致11.运用两个或多个单学科模型可以实现一个组织的集成化过程改进。
CMMI级过程域讲解
CMMI级过程域讲解CMMI(Capability Maturity Model Integration)是一种用于评估和改进软件开发过程的框架。
它通过对软件开发组织的过程进行评估,为组织提供了一个逐步改进过程的路径,从而提高组织的能力和成熟度。
CMMI框架包括五个过程域,它们是:项目管理、项目支持、要素工程、项目环境和组织过程。
每个过程域都有一组特定的目标和实践,用于评估和改进相关的软件开发过程。
首先是项目管理过程域,它关注的是项目的计划、执行和监控。
它包括了项目管理的三个关键方面:计划制定、项目监控和项目管理。
项目管理过程域的目标包括项目计划的制定、项目资源的分配和控制、项目风险的管理和项目进展的监控。
其次是项目支持过程域,它提供了支持项目管理过程的各种资源和服务。
项目支持过程域包括配置管理、度量和分析、决策分析和解决方案评价等方面。
其目标包括配置管理的实施、度量和分析的开展、决策分析和解决方案评价的应用。
第三个是要素工程过程域,它关注的是软件开发中所使用的各种工具和技术。
要素工程过程域包括需求开发、技术解决方案、产品集成和验证、产品交付等方面。
其目标包括需求开发的实施、技术解决方案的应用、产品集成和验证的实施、产品交付的管理。
第四个是项目环境过程域,它关注的是项目所处的环境因素对项目成功的影响。
项目环境过程域包括了风险管理、分析过程和产品市场分析等方面。
其目标包括风险管理的实施、分析过程的开展、产品市场分析的应用。
最后是组织过程过程域,它关注的是软件开发组织的过程管理。
组织过程过程域包括组织过程的定义、组织过程管理的实施和过程改进等方面。
其目标包括组织过程的定义和实施、组织过程管理的应用、过程改进的管理。
总而言之,CMMI级过程域是一个用于评估和改进软件开发过程的框架。
它包括了五个过程域,分别是项目管理、项目支持、要素工程、项目环境和组织过程。
每个过程域都包含了一系列的目标和实践,用于评估和改进相关的软件开发过程。
PCMMI实践解析CMMI模型概述PPT教案
3.3.1 极限模型
优点
1) 采用简单计划策略,不需 要长期计划和复杂模型, 开发周期短;
2) 在全过程采用迭代增量开 发、反馈修正和反复测试 的方法,能够适应用户经 常变化的需求。
缺点
1) 目前主要在小规模项目上 应用并取得成功,但是否 适用于中等规模或大规模 软件产品,需慎重考虑;
Function Spec
M1…Mn
Product Vision
发布阶段
微软产品周期模型
QFEs RTM/W Golden Masters
RC1…RCn
第27页/共46页
Beta
CC ZBB Alpha 测试阶段
本章内容提要
3.1 CMM和ISO9000 3.2 传统软件开发生命周期模型 3.3 扩展软件开发生命周期模型 3.4 质量计划 3.5 案例分析 3.6 本章小结 3.7 复习思考题
开发进度
第15页/共46页
3.2.3 增量模型
增量模型总结
融合了瀑布模型和原型的迭代特征。 每一个增量均发布一个可操作产品。
第16页/共46页
3.2.4 进化模型
听取用户 意见
建造/修改 原型
这个模型可 看作是重复执行 的多个瀑布模型 。
用户测试 运行原型
第17页/共46页
制订计划 决定目标 方案和限制 提交线 评审
功能性 可靠性 易使用性 高效性 可维护性 可移植性
质量规划
─ 指识别哪些质量标准适用于软件项目,并确定如何满足这些标 准的要求
第30页/共46页
3.4.2 质量体系、质量手册和质量 计划
质量体系
─ 指为保证产品、过程或服务质量,满足规定(或潜在) 的要求,由组织机构、职责、程序、活动、能力和资源等构 成的有机整体。
CMMI5文档之决策分析和决定过程
CMMI5文档之决策分析和决定过程决策分析和决定过程文档编号:FHI_CMMI_DAR_PRS文档信息:决策分析和决定过程文档名称:决策分析和决定过程文档类别:CMMI过程密级:内部秘密版本信息:1.1建立日期:2016-1-19创建人:EPG批准人:李庆林批准日期:2016-2-25存放位置:集成公司组织资产库/组织标准过程编辑软件:Microsoft Office 2003 中文版文档修订记录目录1.简介 (4)1.1.目的 (4)1.2.适用范围 (4)1.3.术语表 (4)2.过程总体描述 (4)2.1.概述 (4)2.2.过程结构描述 (4)3.角色和职责 (5)4.过程元素定义 (5)4.1.建立决策组织 (5)4.2.建立评价准则 (6)4.3.识别备选方案 (7)4.4.选择评价方法 (8)4.5.评价备选方案 (9)4.6.选择方案 (10)1.简介1.1.目的决策分析和决定的目的是建立决策分析指导方针,表明在什么样的情况下需要使用决策分析和解决方案过程;建立和维护评价标准并进行分级,用对备选方案进行评价;识别和形成可选的解决方案,对于每个需要决策的问题需要建立若干可选的解决方案;选择评价方法并应用选定的评价方法对备选方案进行评价;根据评价结果选定解决方案。
1.2.适用范围本文档适用于组织内的各类项目,适用于采购和培训部门的采购、培训等活动,也适用于组织内某些重要事件的决策。
1.3.术语表无。
2.过程总体描述2.1.概述该过程简要说明决策分析与决定的工作流程,主要包括形成决策分析指导方针、建立评价标准、识别和形成可选解决方案、确定评价方法等。
2.2.过程结构描述3.角色和职责●公司高级管理层1、召集或参与公司级重大项目或产品研发涉及决策的活动;2、依据公司目标及商业发展规划,指定至多一条评价准则,并确定指定评价准则的等级,但该准则等级值不超过所有评价准则等级值和的30%;3、对决策过程无法确定最终的评价方法时做出最终裁决;4、公司级重大决策活动中经多次评价无法得出结果或者得出两个相近解决方案时,做出最终裁决。
P10-CMMI实践解析-软件度量
度ห้องสมุดไป่ตู้的工作也分两级
组织级度量 项目级度量
让软件过程更简洁、实用
CMMI 实践解析 第十部分 软件度量
让软件过程更简洁、实用
课程概述
1
软件度量概述 度量与分析(MA) 软件度量案例练习
软件度量总结
2
3
4
让软件过程更简洁、实用
度量与分析
将度量与分析活动集成到项目过程中,可支持下列活动:
客观的进行策划与估算 根据建立的计划和目标,跟踪实际绩效
标识与解决与过程相关的问题
让软件过程更简洁、实用
课程概述
1
软件度量概述 度量与分析(MA) 软件度量案例练习
软件度量总结
2
3
4
让软件过程更简洁、实用
案例说明
缺陷的分析是项目管理中比较重要的组成部分,分析的维
度也是多种多样,请从如下角度进行分析: 缺陷数据如何采集 缺陷的数据如何存储 缺陷的数据如何分析 缺陷的数据如何报告
The purpose of Measurement and Analysis (MA) is to
develop and sustain a measurement capability that is used to support management information needs. 度量和分析的目的开发和维护度量能力,目的是支持管理 信息的需求。 相关PA: PP > 估算项目属性和其它计划相关的信息需求。 PMC > 监控项目进展和性能的信息需求。 CM > 管理度量的工作产品。 RD > 满足客户的信息需求和相关的信息需求。 REQM > 管理需求的可跟踪性和相关的信息需求。 OPD > 建立组织级的度量库。 QPM > 使用统计分析技术理解差异。
CMMI全面解析
CMMI全面解析CMMI是英文Capacity Maturity Model Integrated的简称。
中文的译意是能力成熟度集成模型。
CMMI是CMM模型的最新版本。
早期的能力成熟度模型是一种单一的模型其英文缩写为CMM,较多地用于软件工程。
随着应用的推广与模型本身的发展,改方法演绎成为一种被广泛应用的综合性模型,因此改名为CMMI模型。
早期的CMM是美国国防部出资,委托美国卡内基梅隆大学软件工程研究院开发出来的工程实施与管理方法。
目前国内有一种片面地认识,既CMMI是应用于软件业项目管理方法;实际上,CMMI在软件与系统集成外的领域,如科研,工程,甚至于日常的管理都得到了广泛的应用,并取得了相当好的效果。
美国波音公司的120个项目的实施情况表明,由CMMI等级1与等级2提升到等级三,波音的项目估算误差由-120降到-20。
CMMI实际上是一种管理流程的标准化。
遵循该模型的标准,就能够在管理上迈出一大步。
相对于ISO9000的标准, CMMI有五个不同的标准。
而每一个标准对企业的管理力度都有着不同的要求。
企业可以改进管理模式,不断地提高自己的CMMI等级,从而达到提升管理水平的目的。
CMMI虽然源于美国,但在世界各地得到了广泛的推广与接受。
在日本,欧洲,台湾,印度等地都有很多企业在推广与应用CMMI模型。
尤其在印度CMMI的应用甚至超过了美国。
据SEI统计,世界软件企业评估达到5级的共有25个,印度占了其中的16个。
这也是印度软件也得以迅速发展的一个主要原因。
有专家预测在未来的几年内,CMMI将成为ISO9000之后的又一个国际上普遍接受的标准。
在这里我想提一个题外话。
据说我们国家标准局正在制定一个类似于CMMI的国内标准。
我认为这完全没有必要。
CMMI的真正意义在于它能够帮助我们提高项目管理的水平,而不是标准化。
如果我们不能够真正地掌握其管理内涵,而去设立自己的标准,则会是捡了芝麻丢了西瓜。
CMMI 决策分析
3.确定评估方法
决策分析评估表
是否多方案 Y N 4.评估候选方案
5
决策注意点
决策参与者应以公司/部门整体利益为准则,对每一个决策问题
均应认真准备并发表意见,充分沟通,冷静协商,让步、妥协 ,适时做出有效决策。
尊重个人见解。遵从决策的首要原则:没有不同的见解,就不
可能有决策。 善用反面意见。 重视决策相关各方的关注点、实际需求和价值判断。 涉及公司/部门整体利益的重大决策,应重视风险评估和应对措 施。 决策需要勇气。 一经决策,就应着力于决策的实施,化决策为行动。 程进行跟踪,对决策的预期结果做实际印证。
每一项重要决策,均应有相应的信息反馈措施,对决策实施过
第二十一章 决策分析
CMMI中对应实践
决策分析简述
决策分析活动
关于“蓝海战略”
关于“蓝海战略”
《蓝海战略》为企业提供了新的战略思路,即蓝海战略。
这是一种新的战略思路,要求企业:
将视线从市场的供给一方移向需求一方;
从关注并比超竞争对手转向为买方提供新的价值; 分析、筛选和重新排序决定买方价值的关键因素,剔除和降
和执行战略。降低管理风险。
本章结束,谢谢!
低现有的某些价值因素,增加和创造现有产业未提供的某些 价值因素,创造新的价值曲线;
跨越现有市场边界,发现潜在需求,开创、重建市场和产业
边界。
红海战略与蓝海战略区别
红海战略 竞争于已有市场空间
打败竞争对手 开发现有需求
蓝海战略 开创无人竞争的市场空间
摆脱竞争 发现、获取和开创新需求
只能在差异化(效用价值 增加效用价值与降低成本 )和低成本之间权衡取舍 可以同时达到
P01-CMMI实践解析-CMMI模型概述
ML3 已定义级
IPM-集成项目管理 RSKM-风险管理
DAR-决策分析
ML2 已管理级 ML1 初始级
PP-项目策划 REQM-需求管理 PMC-项目监控 SAM-供应商协议管理
MA-度量与分析 PPQA-过程与产品质 量保证 CM-配置管理
让软件过程更简洁、实用
连续式(Continuous)表述方式
37%
62% 50% 14% 4.7:1
2%
9% 7% -4% 2: 1
90%
255% 132% 55% 27.7:1
19
17 20 6 16
让软件过程更简洁、实用
引入CMMI模型的好处 - 波音公司示例
让软件过程更简洁、实用
引入模型的好处 - Motorola公司示例
© Motorola, Inc. 2006
Focus on continuous process improvement
4
Process measured and controlled
已量化 管理级 已定义级
3
Process characterized for the organization and is proactive
2
已管理级
Process characterized for projects and is often reactive Process unpredictable, poorly controlled, and reactive
纪律化的变更是生活的一部分。 从根本上防范缺陷再发生。 系统化地引入新技术、新方法、新工具。 识别并消除低性能产生的长期性原因。 持续进行过程改进。
让软件过程更简洁、实用
质量保证提示 CMMI 决策分析与解决过程
项目管理体系文件决策分析与解决过程编撰人:TMO审核人:批准人:批准日期:保密级别文档版本:1.0信息技术有限公司版本历史目录1.引言 (1)1.1.目的 (1)1.2.适用范围 (1)1.3.术语和缩略语 (1)1.4.参考资料 (1)2.角色与职责 (1)3.入口准则 (2)4.输入 (2)5.流程图 (2)6.主要活动 (3)6.1.决策事项分类 (3)6.2.选择评价方法和建立评价准则 (5)6.2.1.选择评价方法 (5)6.2.2.建立评价准则 (6)6.3.评估候选方案 (7)6.4.做出决策 (7)7.出口准则 (7)8.输出 (8)1.引言1.1.目的决策分析和决定(Decision Analysis and Resolution,DAR)是提供一种正式的处理过程运用结构化方法,对两个或两个以上的候选方案进行决策分析,以此尽量去除主观的判决,使用客观数据,达到选择最优方案的目的。
利用正式的评估过程,依据已建立的准则评估各种已识别的备选方案,以分析可能的决策。
1.2.适用范围本文档是决策小组评估解决方案,进行决策分析,选择适合于当前环境和条件的解决问题的最优方法的依据和指导。
本过程适用于组织内所有重大决策过程,其中包括项目“Make or Buy”等。
本过程适用于进行结构化决策时使用。
1.3.术语和缩略语表1.术语说明1.4.参考资料无。
2.角色与职责表2.决策分析与解决过程角色和职责说明3.入口准则在开发过程中,存在着许多需要进行决策的问题。
但是并非所有问题都需要进行正式的决策分析活动。
只有那些重要的,有重大影响的问题才需要进行正式的决策分析活动。
具体参照“6.1决策事项分类”。
4.输入待决策的问题。
5.流程图流程图如下图所示:图1.决策分析流程6.主要活动6.1.决策事项分类项目在执行过程中,如遇到以下事项,需要进行集体决策。
具体事项及决策参与人员见下表:表3.决策事项分类6.2.选择评价方法和建立评价准则在对决策事项进行决策评估之前,决策小组需要选择评价方法,并且根据所要决策的事项和选择的评价方法确定评估准则,下面详细介绍评价方法及评估准则。
P02-CMMI实践解析-CMMI模型组件
的内容都要参考示例。 例如:PP,SP1.2对规模的举例: 功能数,Number of functions 功能点,Function points 代码行数,Source lines of code 文档页数,Number of pages
让软件过程更简洁、实用
Amplifications 学科扩充
Part Two – Generic Goals and Practices, and the Process Areas (第二部分 主要介绍GG、GP和PA)
Part Three – The Appendices and Glossary (第三部分 附件和术语) References (参考资料) Acronyms (缩写词) CMMI for Development Project Participants (CMMI开发模型参与者) Glossary (术语)
2
3
4
5
让软件过程更简洁、实用
PA的结构
Legend 分类
Required 必须的
Expected 期望的
Informative 提供信息的
让软件过程更简洁、实用
过程域包括如下内容
过程域包括如下内容:
Purpose(目的) Introductory Notes(介绍) Related Process Areas(相关的PA) Specific Goal and Practice Summary(特定目标和实践汇总) Specific Practices by Goal(特定实践)
性的模型组件,它会出现在各过程域,并提供指南以说明 共性实践要如何应用于过程域。
例如:当共性实践”按需要培训人员,以执行或支持已策
CMMI基础知识总结分享
CMMI基础知识总结分享CMMI(Capability Maturity Model Integration,能力成熟度模型集成)是一种用于评估组织软件开发和维护过程的成熟度的方法。
它由Carnegie Mellon大学的软件工程技术研究中心(SEI)开发,并成为许多组织提高其软件开发和维护能力的行业标准。
以下是CMMI的基础知识总结。
1.CMMI模型结构:CMMI主要由过程关键实践(PA)和相关实践(GP)组成。
过程关键实践是为了达到特定目标而必须执行的活动,而相关实践是为了支持过程关键实践而建议执行的活动。
2.成熟度级别:CMMI定义了5个成熟度级别,从初始级别(级别1)到优化级别(级别5)。
每个级别都有一组特定的目标和实践,组织必须满足这些目标和实践才能达到相应的成熟度级别。
3.过程区域:CMMI将软件开发和维护过程分为22个过程区域,如需求管理、项目计划、配置管理等。
每个过程区域都具有一组特定的目标和实践,它们描述了组织在该领域中应该执行的活动。
4.模型应用:CMMI可以被用于评估组织的软件开发和维护能力,帮助组织识别和解决存在的问题,并提供改进的建议。
它还可以用作组织内部的自我评估工具,帮助组织提高其软件开发和维护过程的效率和质量。
5.模型级别:CMMI定义了5个模型级别,分别是初始级别、可管理级别、已定义级别、已量化级别和优化级别。
这些级别反映了组织软件开发和维护过程的成熟度水平。
6.持续改进:CMMI强调持续改进的重要性,组织应该通过不断监控和改进其软件开发和维护过程来提高其能力。
持续改进的目标是提高效率和质量,降低成本和风险。
7.收益和挑战:通过实施CMMI,组织可以获得优势,包括提高工作效率、减少错误和缺陷、提高客户满意度等。
然而,实施CMMI也面临一些挑战,如改变组织文化、开发人员培训和付出的时间和资源投入等。
8.与其他模型的比较:CMMI与其他成熟度模型如ISO9000和SPICE 有一些相似之处,但CMMI更侧重于软件开发和维护过程的成熟度评估和改进。
CMMI 软件工程
CMMI 软件工程CMMI 软件工程简介CMMI(Capability Maturity Model Integration)是一种软件工程能力成熟度模型,用于评价和提升组织的软件工程能力。
它提供了一组最佳实践指南,匡助组织改进和优化其软件开辟过程,以提高软件质量、提高项目管理效率和降低风险。
软件工程能力成熟度模型软件工程能力成熟度模型是评估和改进组织软件工程能力的一种工具。
CMMI是目前应用最广泛、最权威的软件工程能力成熟度模型之一。
它由美国计算机学会(ACM)和美国软件工程研究所(SEI)联合开辟,并在全球范围内广泛应用。
CMMI包含5个不同的成熟度等级,从初始级到优化级分别为:1. 初始级:过程未被那末系统地定义和执行。
2. 管理级:过程被管理以确保可重复性。
3. 定义级:过程被定义和标准化,以确保一致性。
4. 量化管理级:过程的结果被定量地测量和控制,以实现质量管理。
5. 优化级:过程的持续改进。
CMMI框架结构CMMI框架结构由两个主要组成部份组成:持续性和能力。
持续性持续性组成部份包括CMMI模型的共同元素,它们适合于各种不同领域的组织。
这些元素包括:- 成熟度级别:描述了组织软件工程过程成熟度的5个级别。
- 指南:提供了一些指导方针,匡助组织在每一个成熟度级别上改进其软件工程过程。
- 验证和审计:包括对组织软件工程能力的验证和审计过程。
- 改进计划:匡助组织开展改进活动并跟踪其改进进度的计划。
能力能力组成部份是针对特定领域的CMMI模型,例如软件工程、系统工程等。
CMMI软件工程模型是最为常用的能力组成部份。
该模型定义了一个层次结构,包含若干核心能力和过程区域。
核心能力包括:1. 要求管理:管理对软件产品和过程的需求和需求变更。
2. 项目管理:管理软件项目的进度、成本、质量和风险。
3. 工程过程:定义和执行软件开辟和维护过程。
4. 支持过程:提供支持和管理软件开辟和维护过程的服务。
cmmi decision analysis and resolution -回复
cmmi decision analysis and resolution -回复CMMI (Capability Maturity Model Integration) Decision Analysis and Resolution 是一个在软件开发与管理领域广泛使用的过程改进模型。
它提供了决策分析与解决方案的指导,旨在帮助团队和组织做出明智的决策,并高效地解决问题。
本文将分步解答与CMMI Decision Analysis and Resolution 相关的问题,介绍该模型的基本原理和应用方法。
第一步:理解决策分析和解决方案概念首先,我们需要理解决策分析和解决方案的含义。
决策分析是一种系统的方法,用于收集和评估决策所需的信息,帮助制定最佳的决策策略。
解决方案指的是用于解决问题或达到特定目标的方法、工具、技术或策略。
第二步:了解CMMI Decision Analysis and Resolution 模型CMMI Decision Analysis and Resolution (DAR) 模型是CMMI的一个过程领域,旨在帮助软件开发与管理团队做出明智的决策和解决问题。
它包含一系列的实践指南,覆盖了决策分析和解决方案的各个方面。
第三步:理解CMMI Decision Analysis and Resolution 模型的目标和特点CMMI DAR模型的主要目标是帮助团队和组织在决策过程中做出准确、明智的决策,提高决策的质量和可靠性。
它具有以下特点:1. 组织性:CMMI DAR模型要求团队和组织建立一个决策分析和解决方案的框架,通过明确的角色分配和流程定义来促进与团队和组织的合作。
2. 系统性:CMMI DAR模型强调将决策过程与组织的目标及策略紧密相连,确保决策是基于对目标的全面理解,并能够顺利推进组织的发展。
3. 可度量性:CMMI DAR模型强调测量与评估决策的效果和影响,通过采集和分析决策数据来持续改进决策过程。
cmmi解析
cmmi解析全称是即软件能力成熟度模型集成,是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制的,其目的是帮助软件企业对软件工程过程进行管理和改进,增强开发与改进能力,从而能按时地、不超预算地开发出高质量的软件其所依据的想法是:只要集中精力持续努力去建立有效的软件工程过程的基础结构,不断进行管理的实践和过程的改进,就可以克服软件开发中的困难为改进一个组织的各种过程提供了一个单一的集成化框架,新的集成模型框架消除了各个模型的不一致性,减少了模型间的重复,增加透明度和理解,建立了一个自动的、可扩展的框架因而能够从总体上改进组织的质量和效率主要关注点就是成本效益、明确重点、过程集中和灵活性四个方面分5个级别1,完成级在完成级水平上,企业对项目的目标与要做的努力很清晰,项目的目标得以实现但是由于任务的完成带有很大的偶然性,企业无法保证在实施同类项目的时候仍然能够完成任务企业在一级上的项目实施对实施人员有很大的依赖性 2,管理级在管理级水平上,企业在项目实施上能够遵守既定的计划与流程,有资源准备,权责到人,对相关的项目实施人员有相应的培训,对整个流程有监测与控制,并与上级单位对项目与流程进行审查企业在二级水平上体现了对项目的一系列的管理程序这一系列的管理手段排除了企业在一级时完成任务的随机性,保证了企业的所有项目实施都会得到成功3,定义级在定义级水平上,企业不仅能够对项目的实施有一整套的管理措施,并保障项目的完成;而且,企业能够根据自身的特殊情况以及自己的标准流程,将这套管理体系与流程予以制度化这样,企业不仅能够在同类的项目上升到成功的实施,在不同类的项目上一样能够得到成功的实施科学的管理成为企业的一种文化,企业的组织财富4,量化管理级在量化管理级水平上,企业的项目管理不仅形成了一种制度,而且要实现数字化的管理对管理流程要做到量化与数字化通过量化技术来实现流程的稳定性,实现管理的精度,降低项目实施在质量上的波动5,优化级在优化级水平上,企业的项目管理达到了最高的境界企业不仅能够通过信息手段与数字化手段来实现对项目的管理,而且能够充分利用信息资料,对企业在项目实施的过程中可能出现的次品予以预防能够主动地改善流程,运用新技术,实现流程的优化企业在实施的时候,路要一步一步地走一般地讲,应该先从二级入手在管理上下功夫争取最终实现的第五级历史背景的在XX年发布了过程成熟度模型( ) XX年发布了软件的能力成熟度模型SW-()可以视为的领域的起点自此以后,人们开发了各种模型,譬如美国联邦航空管理局()开发了-,集成了其三个模型的所有特征和实践XX年正式发布 XX年12月发布XX年全面替换目前普遍在使用的是的标准,正在审批阶段的是的标准,它们改进的主要方向是完善定义以及可实施性 (能力成熟度模型综合) 涵盖以下几个方面:该模型提供了一套可供公众使用的准则;这些准则描述那些成功地实施了过程改进的组织的特性该模型用“软件能力成熟度”来衡量这种综合能力;阶段式表示的五个成熟度级别初始级–已管理级–已定义级–量化管理级 - 持续优化级 -每个级别都有不同的 (PA,某一个方面),过程域,下面是各个级别所的过程域: 1级- 初始级2级- 已管理级,涵盖了7个PA配置管理、过程与产品质量保证、度量与分析、供应商协议管理、项目监督与控制、项目计划需求管理3级-已定义级涵盖了11个PA决策分析与解决方案、确认、验证、产品集成、技术解决方案、需求开发、风险管理、集成项目管理、组织级培训、组织过程定义、组织过程焦点 4级-量化管理级,涵盖了2个PA 组织过程性能、定量项目管理 5级-持续优化级,涵盖了2个PA组织革新与部署、原因分析与解决方案对于常见的疑问是:不通过2级能过3级吗?3级的企业研发总体成本比2级的要高?怎样才算通过了某个级别的评估呢?评估与审核有何不同?很多公司说自己整体过了多少级,什么叫“整体过”呢?我们自己的公司处于第几级?对于1级,未设定任何标准在各个级别有详细的标准要通过高级别的评估,必须要满足其低级别的所有标准如果该级别的全部PA达到要求了,就认为该级别达到了如果判断PA达到要求呢?每个PA包含几个目标()如果这几个目标都达到要求了,就认为该PA达到要求了如果判断达到要求呢?每个包含几个实践()每个实践达到要求了,就认为该达到要求了评估一个企业是否达到某级别的标准,评估的关键就是每个的实际情况根据评估办法的严谨程度,有以下办法:C、 B、 A(正式评估用的办法)某企业通过了某某级别的评估,意味着什么?评估是对企业准备的几个评估项目按照的标准进行检查企业可以准备任意数量的项目,评估的项目是企业自己指定的通过评估,只代表评估小组认为参加评估的几个项目达到了某个级别的标准通过评估,不代表这个企业其他项目也达到了要求,也不代表该企业后续项目也会达到这个标准企业的商业目标加快进度-- 相同的项目规模,需要更少的时间完成减少成本-- 相同的项目规模,需要更少的成本完成提高质量-- 相同投入情况下,质量更高终极目标:更高的利润!企业商业目标与的关系是为了支持企业的商业目标的不是用来增加管理成本而不提高收益的更高级别的企业,它的效能应该更高效能=收益/投入吃饭“例子“项目”需求如下: -->某个时间,公司进行聚餐活动-->请你组织这次活动,目的是用合理的经费让大家高高兴兴地吃一顿用1-5级如何管理?第1级:初始级第2级:已管理级第3级:已定义级第4级:量化管理级第5级:持续优化级1:初始级-->不用做什么计划,提前一点订好座位-->当天下班大家一哄而去-->现场点菜,然后大吃一顿结果变为:-->定不到位?-->菜不合大家口味-->经费超出预算-->大家心情变得很沮丧问题:有没有可能取得比较好的效果呢?这样做会有什么结果?-->大家吃的满意?-->预算控制得好-->老板高兴真的能够这样吗? 2级做法的一些遗留问题?不需要进行风险管理吗?用什么方法调查大家喜欢吃什么菜式呢?有指南就好了?如何组织聚餐活动是不是有个指导?或者有成功经验可供参考? 3:已定义级经过一段时间积累,以下活动都有明确的指导文档:-->如何写计划-->如何组织吃饭现场活动-->如何确定餐单对于确定餐单、选定酒水供应商方面采用决策分析的办法进行风险管理建立了相应的培训制度另外,为了让组织聚餐活动越做越好,成立了专门的来维护文档这样做的结果??这次活动的几率大大提高了但谁能拍胸口说:一定能够成功? 3级遗留的问题感觉成功机会提高了很多,但没有一个底?最好能有个数字能说明问题 4: 定量管理级积累了大量聚餐活动的、数据积累了大量的聚餐满意度数据当前活动反应聚餐活动能力的数据、满意度等在一定范围内波动根据当前、,可预测聚餐活动的最终成本通过这些数据对活动进行监控4的特点:组织过程性能根据历史数据,算出了性能基线、性能模型定量项目管理聚餐活动进行时,利用性能基线、性能模型进行定量管理这样做会有什么结果?聚餐活动进展情况了如指掌比较准确的估计到最后的结果成功的几率大大提高 4带来的想象哇!4已经非常厉害了更厉害的5会是怎样呢?猜猜? 5: 持续优化级如何持续改进?-->原因分析-->采用新技术-->公司定下新的目标 5 之原因分析通过数据,我们发现由A君组织的聚餐活动,满意度总能在基线范围内但由B君组织时,满意度异常的高,超出了基线上限于是我们进行了原因分析,发现了B君进行抽奖活动之前,做了个调查,知道哦啊每个人最想要什么故抽奖活动进行得很出色,满意度就高了 5之原因分析抽奖活动之前先进行调查这个工作,在过程文档里面并没有规定的,是B君的特殊做法异常高兴,把B君的做法写入过程中于是全部人都按照这个做法去做了,结果满意度性能基线上升了对于一些特殊问题、特殊情况进行分析,可以得到改进过程的机会对过程进行改进后,我们的性能会提高5之采用新技术出现了这样的一些问题:发现难以统计到场的人员,经常去问很多人不知道如何去就餐地点为了解决这个问题,采用如下新技术:每个人配一台和,里面有地图,活动组织者用笔记本电脑能见到各位位置采用新技术后,大家准时出席率提高,并且满意率也提高 5之公司定下新的目标预算的偏差率当前值是-20%到20%,老板觉得很不满意,期望改进为-10%到10% 就非常紧张,投入大量人力物力分析如何改进发现导致预算偏差大的地方主要在于酒水采购方面,供应商的价钱浮动太厉害定下改进计划,修改了采购方面的过程,对供应商的选择加强了标准在某次聚餐中施行新的采购过程,结果发现成本偏差果然控制在-10%到10%范围内分析试运行结果后,把过程正式推行,最终满足了老板的要求 5的两个PA 原因分析组织革新与部署技术改进:公司定下新目标通过这个吃饭的分析,能否感受到管理模型的魅力么?重温一下可爱的5个阶段:第1级:初始级第2级:已管理级第3级:已定义级第4级:量化管理级第5级:持续优化级QA职责 QA工程师岗位职责是:一、质量管理体系:1、QA工程师编制项目部质量管理体系策划书,经领导审批后下发执行2、QA工程师根据施工计划提出年度、月度监督检查计划计划内容要依据质量管理体系文件,并每年监督检查要覆盖项目部所有部门和体系涉及的所有要素3、现场监督检查是随机的、不定时的,QA工程师对监督发现的不符合或缺陷做出记录,并将不符合或缺陷按重要性的不同以书面或口头形式通知责任方目的在于向责任方提出改进工作的建议,提醒责任方引起重视,纠正不符合和缺陷4、巡检主要针对单位工程开工、施工过程中、三级验收及监理公司参与的四级验收之前,QA工程师提前按照程序文件要求对文件包资料进行检查,避免在监理公司验收时提出不符合,同时保证施工与资料同步,避免后补资料5、QA工程师汇总各类管理体系月度、年度监督检查情况,出具报告,报公司企业策划部,并对有关问题提出纠正预防措施,监督实施;6、QA工程师汇总各部门年度体系培训计划,经人力资源管理批准后,各部门组织实施7、QA工程师配合质监专工参与质监中心站活动,并依据有关要求整理迎检资料,对各部门的资料提前组织检查8、QA工程师与各部门保持密切联系,及时解决体系运行中接口不协调的问题,如无法解决可提交管理评审输入9、QA工程师配合好与业主及监理公司进行的各种质保监督检查活动,及时组织对检查出的质量问题进行整改,并采取纠正或预防措施10、QA工程师与各专业工程师、单项工程师密切配合,抓好不合格品的控制出现不合格品,要及时进行原因分析并做好统计记录工作,采取有效的纠正预防措施,杜绝类似质量问题再发生11、QA工程师根据每年公司质量体系审核、日常监督检查、质量评定情况、管理评审以及顾客反映的有关问题,进行全面的汇总统计分析,找出质量体系运行的薄弱环节以书面报告的形式反馈相应的部门,并由其制订预防措施和质量改进目标,实现质量改进 12、QA工程师配合好公司组织的质量管理体系内审,并对出现的不符合组织整改13、QA工程师配合好由认证单位组织的外审,并对出现的不符合组织整改 14、QA 工程师对有关招标文件从体系考虑角度进行审查 15、QA工程师每周不少于一次到现场检查16、QA工程师每月不定期对重要进货物资、监视设备、文件包等资料进行抽检二、计量管理体系:1、QA工程师组织项目部有关人员学习贯彻执行国家计量法律、法规、法令及公司程序文件2、QA工程师组织建立项目部量值溯源图3、QA工程师建立项目部管理人员网络图4、QA工程师负责项目部管理部门使用检测设备的日常计量管理工作5、QA工程师负责项目部计量检测体系的运行及日常的监督6、QA工程师负责项目部计量管理信息的上传下达7、QA工程师负责建立项目部计量检测设备台帐,并上报企业策划部 8、QA工程师负责项目部计量检测设备的送检工作 9、QA工程师负责批准各部门检测设备需用计划的提出10、QA工程师负责检测设备的封存、报废、回收等管理工作11、QA工程师配合人力资源做好项目部员工的计量教育、培训工作,不断更新职工的计量知识,提高员工的计量意识12、QA工程师配合好公司组织的计量管理体系内审,并对出现的不符合组织整改13、QA工程师配合好由*机构组织的外审,并对出现的不符合组织整改 14、QA工程师负责监督检测设备的贮存和使用情况 15、QA工程师每周不定期对检测设备进行抽查16、QA工程师每月对外包队使用计量器具的情况进行抽查三、环境管理体系:1、QA工程师每年组织环境因素的识别与评价,汇总报批重要环境因素2、QA工程师汇总报批环境目标、指标、环境管理方案,并监督验证实施3、QA 工程师组织各部门编制项目部环境管理体系文件4、QA工程师负责与电厂、监理公司等的外部联络,接收外部相关方的投诉5、QA工程师组织制定项目部环境管理体系年度培训计划人力资源负责培训的组织、落实和记录管理6、QA工程师参与项目部能源、资源的节约控制;参与自然灾害的防范,现场事故的预防、应急准备和响应;参与消防设计评审;参与确定生活和生产活动中的环保监测项目和关键特性;参与生产施工过程噪声、振动、烟尘、污水排放控制7、QA工程师为各责任部门的培训提供技术支持;各责任部门负责实施 8、QA工程师每月对废弃物处理的情况进行监督检查9、QA工程师负责组织项目部的应急准备和响应,建立应急方案,并监督实施 10、QA工程师对监测设备和仪器进行统一管理、每月进行抽检11、QA工程师协助处理环境事故,协助责任部门分析不符合项产生原因,制定并实施纠正和预防措施,QA工程师监督实施12、QA工程师配合文明施工员每周至少二次到现场检查,形成环境记录13、QA工程师协助、配合公司组织的内审工作;为管理评审提供需要的信息14、QA工程师负责接收公司的信息并及时传达;负责汇总项目部的信息并按要求上报15、QA工程师每月对主管部门环境特殊、重要岗位人员相关知识、技能的培训情况进行监督检查 16、QA工程师每半年对法律、法规及其它要求的遵守执行情况进行监督检查四、职业安全健康管理体系:1、QA工程师配合安监专工编制职业安全健康体系策划书,配合安监人员对职业安全健康体系运行的整体情况进行策划2、QA工程师组织编制、修订、发放项目部职业安全健康体系文件;3、QA工程师参与安全质量会议;4、QA工程师参与公司、项目部组织的月度、季度安全大检查5、QA工程师监督验证检查中提出的体系性不符合的纠正和预防6、QA工程师参与对工程分承包方资料的评价,并对其施加影响提出建设性意见和建议7、QA工程师每月对的收集和发放进行检查、每月对化学危害品的使用检查8、QA工程师配合安监专工对项目部的应急预案和响应方案的建立、实施情况进行检查; 9、QA工程师检查各部门目标的分解和管理方案的落实情况软件qa工程师职责对比分析无论是9还是,都是以过程为中心也就是说,通过过程的持续改进来提高产品质量而过程质量与产品质量如何正向关联呢?就需要质量保证这也是9和都很推崇的方法但从国内软件企业的现状来看,很多企业的过程体系都相差无几,而开发出来的产品质量却千差万别导致这种差别的原因有很多,过程及其执行方式的生搬硬套就是其中很重要的原因之一在建立QA组织的时候,多数企业也这样实行“拿来主义”就像看着别人穿着一双非常漂亮的鞋,就想拿过来自己穿,一般都不会适合自己其结果要么是打肿脚穿大鞋,要么是削足适履,效果可想而知我们应该做的是“量脚买鞋”、“量体裁衣”QA组织的建立也一样,应先了解企业的文化、可获得的资源以及过程成熟度水平等,再据此选择适宜的QA组织下面我们就从一个动态的视角来探讨QA组织的建立建立组织结构建立一个组织,首先需要考虑的是它的组织结构组织结构不仅在很大程度上决定了岗位的职责,而且还决定了资源如何配置按照国内多数企业的做法,QA组织结构可划分为三类:职能结构、矩阵结构以及两者结合而成的柔性结构职能结构在职能结构中,各个职能部门设立自己的QA岗位,位于高级经理之下,独立于项目组QA直接对高级经理负责,但业务上需要向项目经理汇报,属于项目成员如图1所示这种组织结构的优点是QA容易融入项目组,易于发现实质性的问题,解决问题也很快捷缺点是各职能部门相对独立,部门之间的经验缺乏交流和共享,还可能出现对过程、方法和工具研究的重复性投资在这种组织结构下,由于高级经理专注于业务的发展,QA的职业发展容易受到忽视,难于接受到应有的培训和提升矩阵结构在矩阵结构中,设立了专门的QA部门,与各业务职能部门平级QA隶属于QA部,行政上向QA经理负责,业务上向业务部门的高级经理和项目经理汇报如图2所示在这种组织结构中,由QA部经理对QA考评和授权,有利于保证QA的独立性和评价的客观性,也有利于确保组织的长期利益与项目的短期利益之间的平衡QA资源为所有项目所共享,可按照项目优先级动态调配,资源利用更充分,但也可能出现资源竞争冲突此外,QA 部门对QA流程的改进、QA知识的管理、QA人员的发展负责,并可集中资源进行QA平台的建设,以防止重复性的投资但另一方面,在矩阵结构中,QA难于融入项目组,发现的问题也很少能得到及时有效的解决柔性结构柔性结构是职能结构和矩阵结构的混合形态,在职能结构的基础上建立了QA组专业组QA组是一个专业组,不是一个行政机构可由质量管理部委派人员担任或由某业务部门的QA兼任与职能机构一样,QA直接对高层经理负责,但在业务上向项目经理和汇报柔性结构吸收了职能结构和矩阵结构的许多优点,既便于QA融入项目组,又便于部门之间经验的分享,还利于QA能力的提高可以从各部门QA汇报中提取出各项目的共性问题,用于组织级过程的改进企业还可以通过授予不同的权利,比如按照2/8原则与高级经理分配QA的管理,来促进QA专业研究与应用的结合QA可以协助评审和组织会议;在存在外包的情况下,可能需要QA在监控外包方方面发挥作用重要责任过程成熟度是影响QA职责分配很重要的因素,不同的成熟度等级所要求的QA工作分布是不同的在低成熟度等级下,需要抽取各项目最佳实践来定义过程,并指导过程的实施,QA在这方面的工作最多随着过程的完善、制度化和实施,QA的工作重点逐渐转向了过程评审和产品审计当企业的过程成熟度达到4级或5级以后,对过程的遵守已经成为员工的一种习惯,过程和产品的审查需求减少,而度量和过程能力的优化又成为QA的工作重点企业文化对QA来说就像空气一样,看不见它,但却深深地被它影响比如说,在一个氛围活跃、高技术、创新能力强的企业,QA应该倾向于服务职责;而在一个强纪律、低技术、规章制度成熟的企业,QA就应该倾向于监督职责QA工程师国内企业越来越注重产品质量,随之,对品质监管的力度与要求也越来越高QA工程师水涨船高,备受重视QA的薪金是跟工作年限成正比的那么,经验丰富的QA工程师都需要掌握些什么呢? 1) 相关体系的认证及完善 2)主管技术措施和技术、质量、安全的交底工作 3)一般性品质工作 4)质量培训工作5)做品质就像在给病人看病,高手总是能在不良发生之前就解决它所以,QA ,最重要的是一个预防性作用 1根据工程资料内部要求及时对产品的有关项目组织实验室测试 2制订品质计划3对各种材料及成品之检验标准书进行审核 4即时处理客户抱怨及退货以确保客户满意5主持每周品质会议并推动全公司相关部门人员共同提升品质 6统计、分析各品质会议并推动全公司相关部门人员共同提升品质 7统计、分析各阶段品质不良并推动各部门改善以达到目标 8针对材料不良辅导供应商分析、改善 9做好品质记录以便追溯1稽核评估供应商并做好相应记录 11考核下属业绩配置岗位人员在建立组织结构过程中设立了QA工作岗位,就需要为岗位配备足够的资源,特别是分派岗位人员从大体上说,QA人员的配备可根据企业特点分为两类:全职和兼职全职就是设置专门的QA人员,QA的主要职责就是质量保证工作在设置这类人员时,最重要的是考虑他的知识、技能和素质是否符合组织和岗位的规定和要求这些要求是依据企业文化和成熟度的不同而有所侧重比如说,对于一个协作意识较弱、官僚主义较浓的企业,沟通对QA来说可能是一个重要的素质要求;对于成熟度较低,还没有制度化标准过程的企业,对业务的了解和QA专业知识的精通可能是选择QA最重要的标准兼职就是将工程师分派到其它职能部门或项目中去兼任QA工作,每一位工程师都作为一名潜在的QA这也是QA人员配置的一个可选方案,一般适宜于开放的、以质量为向导的文化,反过来也能对质量文化的建设起到很大的促进作用但这种方案应小心地与组织制度结合,比如奖惩制度、成本制度等,否则容易引起利益冲突由于QA的概念引入国内不久,QA人才相当缺乏为了获得足够的资源来完成QA工作,也可以采取岗位轮换的方式比如,允许项目经理在项目管理岗位和QA岗位上轮换,把一定的QA工作经历作为项目经理上岗的必备条件采取岗位轮换的方式,一方面解决了QA资源的不足,另一方面还促进了轮岗人员把QA的思想和方法融会到开发和项目管理工作中,更大程度上提高产品质量从以上的分析我们可以知道,建立QA组织需要动态地考虑企业的文化、可获得的资源以及过程成熟度水平等因素,做到“因地制宜”,而不是生搬硬套首先要建立一个适宜的组织结构,组织结构中确立了QA岗位和汇报渠道接下来就是确定岗位职责,并根据岗位职责的要求配置合适的QA人员只有在组织结构、岗位职责、岗位人员都设置和整合好以后,才能充分发挥QA的价值,确保通过过程的持续改进来带动产品质量的不断提高工作内容在需求定义流程中,审查是更适合质量保证测试人员的角色,而不是定义;但QA测试人员需要学习如何高效执行审查对于QA测试人员来主产,在于需求定义审查中成功获得支持关键在于,找到对于其它参与人员重要的问题,这就意味着找出需求内容相关的问题,避免投入过多的精力在形式和可测试性上在我的书中,或相关的讨论坛中,我描述了许多方法来识别需求问题——包括清晰度和可测试性——以及如何使用强大的方法来检测出错误和疏忽的内容有些组织让业务分析师负责定义需求和开发测试,从而证明需求已经达到要求这类双重角色常常会因为测试方法和知识的不足,而导致测试被忽略掉另外,分析师的测试。
P10-CMMI基础知识培训-项目和组织支持之决策分析
SEI Transition Partner
13
SEI Transition Partner
决策之后
经过正式的决策方法决策之后注意以下问题: –决策的结果和心理的期望是否一致。 –决策后对采用的方案是否进行风险分析。
14
SEI Transition Partner
10
案例二 人力外包决策
人员的技能(具备所要求技能情况) 人员资质(所要求的资质证书) 合作项目历史(以往合作的情况) 工具熟练程度(开发工具的掌握情况) 价格因素(外包预算情况)
SEI Transition Partner
11
案例三 第三方软件采购决策
SP1.4 选择 评价方法
提议的选项
方法
SP1.6 选择 方案
SP1.5 评价 备选方案
8
课Байду номын сангаас概述
1 决策分析概述 2 决策与分析(DAR) 3 决策分析的准则设计
4 决策分析总结
SEI Transition Partner
9
案例一 技术方案决策
技术限制(是否有成功案例) 环境影响(运行环境,性能) 进度影响(导致的进度偏差) 风险(技术风险) 生命周期成本(成本因素)
3
课程概述
1 决策分析概述 2 决策与分析(DAR) 3 决策分析的准则设计
4 决策分析总结
SEI Transition Partner
4
SEI Transition Partner
Decision Analysis and Resolution(决策分析)
The purpose of Decision Analysis and Resolution (DAR) is to analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria. 决策分析的目的是使用正式的评价流程,基于建立的评价准 则,评价备选的方案,进行决策分析。 相关PA:
质量保证提示CMMI决策分析与解决过程
项目管理体系文件决策分析与解决过程编撰人:TMO审核人:批准人:批准日期:XX级别文档版本:1.0信息技术XX版本历史目录1.引言1 1.1.目的11.2.适用X围11.3.术语和缩略语11.4.参考资料12.角色与职责23.入口准则24.输入25.流程图26.主要活动3 6.1.决策事项分类36.2.选择评价方法和建立评价准则56.2.1.选择评价方法56.2.2.建立评价准则76.3.评估候选方案76.4.做出决策77.出口准则88.输出81.引言1.1.目的决策分析和决定(Decision Analysis and Resolution,DAR)是提供一种正式的处理过程运用结构化方法,对两个或两个以上的候选方案进行决策分析,以此尽量去除主观的判决,使用客观数据,达到选择最优方案的目的。
利用正式的评估过程,依据已建立的准则评估各种已识别的备选方案,以分析可能的决策。
1.2.适用X围本文档是决策小组评估解决方案,进行决策分析,选择适合于当前环境和条件的解决问题的最优方法的依据和指导。
本过程适用于组织内所有重大决策过程,其中包括项目“Make or Buy”等。
本过程适用于进行结构化决策时使用。
1.3.术语和缩略语表1.术语说明1.4.参考资料无。
2.角色与职责表2.决策分析与解决过程角色和职责说明3.入口准则在开发过程中,存在着许多需要进行决策的问题。
但是并非所有问题都需要进行正式的决策分析活动。
只有那些重要的,有重大影响的问题才需要进行正式的决策分析活动。
具体参照“6.1决策事项分类”。
4.输入待决策的问题。
5.流程图流程图如下图所示:图1.决策分析流程6.主要活动6.1.决策事项分类项目在执行过程中,如遇到以下事项,需要进行集体决策。
具体事项及决策参与人员见下表:表3.决策事项分类6.2.选择评价方法和建立评价准则在对决策事项进行决策评估之前,决策小组需要选择评价方法,并且根据所要决策的事项和选择的评价方法确定评估准则,下面详细介绍评价方法及评估准则。
我对CMMI2.0PLAN实践域的理解和分析
我对CMMI2.0PLAN实践域的理解和分析策划(PLAN)实践域对应的是前版的PP过程域,但2.0版比前版增加了很多变化。
•变化1:在2.0版的计划内容和本实践域的价值中都增加了“质量”,因为2.0把质量目标达成作为项目成功因素之一。
•变化2:2.0版的策划不仅只有2级实践,而是覆盖了1~4个等级的实践。
•变化3:前版中关于估算的实践,在2.0中已经独立为一个实践域,只保留了“定义项目生存周期”实践。
•变化4:增加了关于运营和迁移的策划实践。
•变化5:将前版中的一些实践进行合并。
•变化6:将前版IPM过程域的一些实践纳入到本实践域中。
•变化7:增加使用组织过程来开发和维护项目过程的实践。
•变化8:增加使用统计和量化技术来开发和维护项目过程的实践。
本实践域共4个等级15个实践。
第1级实践1.1是根据所了解的项目目标,直接给出完成项目必须执行的任务列表。
实践1.2是根据所了解的人员情况,将任务分配到人员。
第1级实践就是原始的项目策划,因为没有什么依据,自然也没有太多有效性。
第2级实践2.1是根据组织的业务目标、项目目标和项目范围来定义项目的生命周期,以及识别出项目资源、相关方和风险。
前版PP过程域SP1.3“定义项目生存周期”、SP2.2“标识项目风险”、SP2.4“制定项目资源计划”都是本实践的内容。
实践2.2对应前版PP过程域SP2.5“策划所需的知识和技能”。
但在2.0中对知识和技能的策划给出了更多的建议。
首先对知识和技能的认知上,2.0给出了一些关键技能的示例。
这些示例表明项目成员除了掌握与软件开发和使用工具设备等硬核技能之外,还应掌握诸如沟通这样的软技能。
其次,2.0中给出了一些找出人员现有技能和项目所需技能差距的方法:个人的自我评估、个人的先前经验、测试、培训记录等。
实践2.3对应前版PP过程域的SP2.1“编制预算和进度表”,二者基本雷同。
PS:关于关键路径的问题。
在GJB5000A评价时,经常有评价员会打出项目的进度表中未给出关键路径的问题。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
11
SEI Transition Partner
案例三 第三方软件采购决策
软件的功能(功能满足情况) 软件的性能(性能满足情况) 产品成熟程度(在市面上应用的程度) 产品的成功案例(成功应用的客户数) 价格因素(产品的价格) 学习成本(是否容易上手使用)
12
SEI Transition Partner
课程概述
决策分析概述 决策与分析(DAR) 决策分析的准则设计
决策分析总结
1
2
3
4
2
SEI Transition Partner
概述
决策分析与解决方案过程域包括建立指南,以决定什么问题 需要正式评价过程,然后引用正式评价过程解决问题。 正式评价过程为结构化的方法,按照已建立的准则评价候选 解决方案,并决定推荐的方案。
SP1.1 建立 决策分析 指南 SP1.4 选择 评价方法
SP1.2 建立 评价标准
SP1.3 识别 备选方案
其它过程域
指南
标准
提议的选项
方法
SP1.6 选择 方案
SP1.5 评价 备选方案
8
SEI Transition Partner
课程概述
决策分析概述 决策与分析(DAR) 决策分析的准则设计
3
SEI Tra 决策与分析(DAR) 决策分析的准则设计
决策分析总结
1
2
3
4
4
SEI Transition Partner
Decision Analysis and Resolution(决策分析)
The purpose of Decision Analysis and Resolution (DAR) is to analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria. 决策分析的目的是使用正式的评价流程,基于建立的评价准 则,评价备选的方案,进行决策分析。 相关PA:
决策分析总结
1
2
3
4
9
SEI Transition Partner
案例一 技术方案决策
技术限制(是否有成功案例) 环境影响(运行环境,性能) 进度影响(导致的进度偏差) 风险(技术风险) 生命周期成本(成本因素)
10
SEI Transition Partner
案例二 人力外包决策
人员的技能(具备所要求技能情况) 人员资质(所要求的资质证书) 合作项目历史(以往合作的情况) 工具熟练程度(开发工具的掌握情况) 价格因素(外包预算情况)
– PP > 项目策划。 – IPM > 建立项目定义的过程。项目定义的过程通常包括正式评价流
程,用于对不可预见问题的正式评价。 – RSKM > 识别及缓解风险。正式评价流程通常适用于中到高风险项。 而所选择的解决方案通常会影响风险缓解/应对计划。
5
SEI Transition Partner
Decision Analysis and Resolution(决策分析)
SEI Transition Partner
Continental Reaching Solutions
CMMI 实践解析 第十二部分 决策分析
Continental Reaching Solutions Technologies 上海连陆信息技术有限公司
SEI Transition Partner
6
SEI Transition Partner
目标之间关系解析 - SG1
SG1
Evaluate Alternatives (评价备选方案)
Stakeholders (相关干系人)
• 决策报告 • 决策记录 其它过程域
7
SEI Transition Partner
SG1 评价备选方案
SG1
Evaluate Alternatives (SG1 评价备选方案)
Continental Reaching Solutions Continental Reaching Solutions
谢
谢!
Continental Reaching Solutions Technologies 上海连陆信息技术有限公司 2007年5月
课程概述
决策分析概述 决策与分析(DAR) 决策分析的准则设计
决策分析总结
1
2
3
4
13
SEI Transition Partner
决策之后
经过正式的决策方法决策之后注意以下问题: –决策的结果和心理的期望是否一致。 –决策后对采用的方案是否进行风险分析。
14
SEI Transition Partner