CMMI的5个等级记忆法(夏娃法与路法)_菜头
软件能力成熟度模型的五个等级
软件能力成熟度模型的五个等级软件能力成熟度模型的五个等级导语：在软件开发和管理领域，软件能力成熟度模型（Capability Maturity Model，简称CMM）是一个被广泛应用的评估和改进软件开发能力的框架。
CMM根据不同的组织在软件开发过程中的能力水平，将其分为五个等级，逐步提升组织的软件开发能力。
本文将详细介绍软件能力成熟度模型的五个等级，并对每个等级所代表的特点和优势进行分析。
一、初始级（Level 1 - Initial）初始级是软件能力成熟度模型中最低的等级。
在这个等级中，组织没有明确的软件开发过程，开发工作往往是以临时和非结构化的方式进行的。
在这种情况下，项目的成功往往依赖于个别的开发人员的经验和个人技能。
缺乏标准化的开发流程、文档化的要求和质量控制，容易导致开发过程中的混乱和错误。
二、重复级（Level 2 - Repeatable）重复级是软件能力成熟度模型中的第二个等级。
在这个等级中，组织开始意识到软件开发过程的重要性，并开始建立一些基本的规范、流程和工具来规范开发过程。
组织能够重复地执行一些已经被证明是成功的软件开发实践。
这些实践可以帮助组织在不同的项目中保持一定的一致性，提高软件质量和生产效率。
三、定义级（Level 3 - Defined）定义级是软件能力成熟度模型中的第三个等级。
在这个等级中，组织进一步明确了软件开发过程，并进行了规范化和文档化。
组织能够定义一套标准的开发流程和过程，并将其应用于所有的软件开发项目。
组织还会建立一些针对不同项目要求的指南和标准，以确保开发过程的一致性和高质量。
四、管理级（Level 4 - Managed）管理级是软件能力成熟度模型中的第四个等级。
在这个等级中，组织开始对软件开发过程进行量化和度量，以便对项目进行更加准确和全面的管理。
组织会使用一些度量指标来评估和监控软件开发过程的质量和效率，以及在开发过程中发现和解决问题的能力。
cmmi五个成熟度级别
CMMI 等级的含义五个成熟度级别之间的比较如下：1，初始级特征:(1）软件过程的特点是杂乱无章，有时甚至混乱.几乎没有定义过程的规则或步骤。
(2）过分的尽诺.常做出良好的承诺:如"按照软件工程方式，有序的工程过程来工作"；或达到高目标的许诺。
但实际上却出现一系列危机.（3）遇到危机就放弃原计划过程,反复编码和测试.(4）成功完全依赖个人努力和杰出的专业人才,取决于超常的管理人员和杰出有效的软件开发人员.具体的表现和成果都源于或者说是决定于个人的能力和他们先前的经验，知识以及他们的进取心和积极程度.(5）能力只是个人的特性，而不是开发组织的持性.依靠着个人的品质或承受着巨大压力，或找窍门取得成果.但此类人一旦离去，对组织的稳定作用也消失。
(6）软件过程是不可确定的和不可预见的。
软件成熟性程度处于第一级的软件组织的软件过程在实际的工作过程中被经常的改变（过程是随意的）.这类组织也在开发产品，但其成果是不稳定的,不可预见的，不可重复的.也就是说,软件的计划，预算,功能和产品的质量都是不可确定和不可预见的.过程:(1）极少存在或使用稳定的过程。
（2）所谓"过程”，往往是”就这么干"而言. （3）各种条例，规章制度互不协调,甚至互相矛盾人员：（1)依赖个人努力和杰出人物。
一旦优秀人物离去,项目就无法继续（2）人们的工作方式如同"救火".就是在开发过程中不断地出现危机,以及不断的”救火”.技术: 引进新技术是极大风险度量：不收集数据或分析数据改进方向：（1）建立项日管理过程。
实施规范化管理。
保障项目的承诺。
(2）首要任务是进行需求管理,建立客户与软件项目之间的共同理解，使项目真正反映客户的要求.(3)建立各种软件项目计划.如软件开发计划,软件质量保证计划,软件配置管理计划,软件测试计划,风险管理计划及过程改进计划。
（4）开展软件质量保证活动(SQA）。
cmmi能力成熟度模型口诀
cmmi能力成熟度模型口诀CMMI能力成熟度模型口诀CMMI（Capability Maturity Model Integration）能力成熟度模型是一种用于评估和改进组织软件和系统工程过程的方法，它提供了一套结构化的指南和最佳实践，帮助组织提高软件工程能力和质量。
一、了解CMMICMMI是软件工程领域的一个重要模型，其核心思想是通过评估和改进组织的过程，达到提高软件工程能力和质量的目标。
二、掌握CMMI的五个等级CMMI模型根据组织的过程成熟度分为五个等级：初始级、可管理级、定义级、量化管理级和优化级。
三、初始级：过程不稳定初始级表示组织的过程是不稳定的，无法重复且无法预测。
组织需要进行过程的规范化和标准化，建立起稳定的基础。
四、可管理级：过程可重复可管理级表示组织的过程已经能够在一定程度上重复执行，并且能够进行基本的度量和控制。
组织需要建立过程管理的能力，确保过程的稳定性和可重复性。
五、定义级：过程可管理且可量化定义级表示组织的过程已经被定义和标准化，并且能够进行量化的度量和分析。
组织需要建立度量和分析的能力，以便对过程进行持续改进。
六、量化管理级：过程可控制量化管理级表示组织的过程已经能够进行统计和量化的控制，并且能够预测和优化过程的性能。
组织需要建立过程控制和预测的能力，以便实现过程的持续改进和优化。
七、优化级：过程优化优化级表示组织的过程已经达到最高水平，能够持续改进和优化。
组织需要建立创新和持续改进的能力，以保持竞争优势和持续创新。
八、CMMI的实施步骤CMMI的实施需要经历规划、执行、评估和改进四个阶段。
组织需要制定实施计划，明确目标和时间表，并按照计划执行，评估实施效果并进行持续改进。
九、CMMI的好处通过实施CMMI，组织可以提高软件工程能力和质量，减少开发过程中的错误和缺陷，提高项目的成功率和客户满意度。
同时，CMMI还可以帮助组织建立良好的软件工程文化和团队合作精神。
十、总结CMMI能力成熟度模型是一个重要的软件工程模型，通过评估和改进组织的过程，帮助组织提高软件工程能力和质量。
软件能力成熟度模型等级和过程
软件能力成熟度模型等级和过程在软件开发行业中，软件能力成熟度模型（Capability Maturity Model，简称CMM）是一种用于评估和改进组织软件开发能力的方法。
CMM将软件过程能力分为五个等级，每个等级代表了不同的软件开发成熟度。
在本文中，我将介绍CMM的五个等级和相应的软件开发过程。
第一等级——初始级（Initial）初始级是软件开发团队的起点，特点是开发过程不可预测、不稳定且不受控制。
在这个等级中，软件开发过程通常是一种灵活的方式，缺乏定义和规范。
开发团队的工作主要依靠个人技能和经验，而非标准化方法。
第二等级——可管理级（Managed）当开发团队达到可管理级时，他们开始寻求一种系统化的方法来管理软件开发过程。
这个等级的关键是建立有效的项目管理实践，通过规范化的计划、控制和测量，对项目进展进行管理和监控。
第三等级——已定义级（Defined）已定义级是软件开发过程的一个重要里程碑，它要求开发团队建立起一套标准化的软件开发流程。
这个过程必须经过详细的定义和文档化，以确保团队的工作是可重复的和可预测的。
第四等级——量化管理级（Quantitatively Managed）在量化管理级，软件开发团队进一步改进了他们的过程，并引入了更多的量化和度量方法。
这些量化和度量方法是为了监控和管理软件开发过程的关键指标。
通过定期收集和分析数据，团队可以做出有根据的决策，进一步提高软件开发过程的质量和效率。
第五等级——优化级（Optimizing）优化级是软件开发过程的最高级别。
在这个等级中，开发团队持续追求卓越，并通过不断改进软件开发过程来实现进一步的提升。
团队会寻找新的创新方式，试验新的技术和方法，以优化软件开发过程的效率和质量。
综上所述，软件能力成熟度模型将软件开发能力划分为五个等级：初始级、可管理级、已定义级、量化管理级和优化级。
不同的等级代表了软件开发过程的不同成熟度水平，团队可以通过评估自身的成熟度来制定相应的改进计划，并逐步提高软件开发过程的质量和效率。
cmmi认证的五个级别 -回复
cmmi认证的五个级别-回复CMMI（Capability Maturity Model Integration，即能力成熟度模型集成）是软件和系统工程领域中的一种通用过程改进框架，通过评估组织的过程能力，提供了一种逐步改进组织软件和系统工程能力的路径。
CMMI 认证是对组织过程的认可，分为五个级别，分别是初始级、管控级、已定义级、已管理级和优化级。
首先，初始级是CMMI认证的第一个级别。
组织在初始级别下，缺乏明确定义的过程，其实践通常是基于个人技能和直觉而非统一的约束。
这意味着组织的过程不可靠、不稳定，并且缺乏一个良好的管理体系。
在初始级别下，组织可能会经历一些不可预见的挑战和困难。
要达到下一个级别，组织需要开始确立和追踪过程，并收集数据来了解过程的表现。
接下来是管控级。
管控级是组织开始追求稳定过程的级别。
在此级别，组织开始将工作任务、资源和时间进行规划和管理，以确保项目按时完成。
组织开始采用一些重复使用的过程，并关注项目管理和风险管理。
在管控级别下，组织要努力改善过程并确保过程的持续改进。
为了达到下一个级别，组织需要定义并文档化其过程，并对其过程和项目进行定期的评估。
第三个级别是已定义级。
在此级别，组织开始定义过程的规则、程序和活动，并将其记录在文档中。
组织开始制定标准，以确保过程的一致性和质量。
在已定义级别下，组织需要开展员工培训，以确保他们理解并使用过程文档中描述的方法和技术。
组织需要通过内部审计来验证过程的合规性和有效性，并定期进行过程改进。
为了达到下一个级别，组织需要集成过程，以提高效率和质量，并进一步改善过程。
已管理级是CMMI认证的第四个级别。
在此级别，组织已经建立了一套可管理的过程，并可以基于量化的数据进行决策。
组织开始监控和控制过程的执行情况，并对过程进行量化的度量和分析。
这使组织能够预测和缓解风险，并根据过程绩效的实际反馈进行改进。
在已管理级别下，组织还需要开展持续的过程改进活动，并通过度量和分析来优化过程绩效。
CMMI扫盲1至5级简述
CMMI扫盲1⾄5级简述CMMI扫盲摘要：CMMI全称是Capability Maturity Model Integration，CMMI是个好东西来的，但⾏内⼈⼠对她的认识并不全⾯，甚⾄有种种的误解。
尽管⽹上有很多CMMI相关介绍，但⼀般都是⽐较苦涩难懂的。
本⽂将⽤⽣动通俗的语句，让⼤家初步看清楚CMMI的真⾯⾯孔。
CMMI是什么东西？CMMI英⽂全称是Capability Maturity Model Integration，直接翻译就是能⼒成熟度模型，直接看这⼏个中⽂字，你还是没有办法搞清楚CMMI是什么东西的。
⼤家可能在⽹上见过很多《成功⼈⼠的七个习惯》（可能还有很多类似的名字）的⽂章吧？有⼈总结了成功⼈⼠的成功的原因，总结出他们的习惯，如果我们也能具备这些习惯，那么我们也很可能成为成功⼈⼠。
类似的，CMMI可以看作是成功企业如何做好软件的⼀些习惯、做法、准则等的集合，是如何做好软件的最佳实践的集合。
如果企业也能按照CMMI的要求做好，那么企业就很可能成为成功的企业。
CMMI⾥⾯所有的要求，都是来⾃于成功企业的最佳实践的，她的先进性我们不必怀疑，如果我们没有做好，那不是CMMI本⾝的问题，⽽是我们⾃⼰没有理解好或者是没有执⾏好的原因。
说到CMMI，就不可避免会提到另外3个字母SEI，SEI全称是Software Engineering Institute 的全称，直译就是软件⼯程研究所，是美国的⼀所⼤学（卡内基梅隆⼤学CMU）与美国国防部合作成⽴的，CMMI标准就是他们搞出来的。
CMMI⽬前最新版本是V1.2，如果你是现在才开始了解CMMI的，那么你完全没有必要去搞清楚V1.1与V1.2的差别，更加没有必要去⽐较CMM与CMMI的差别，直接了解CMMI V1.2就可以了，你只需要知道CMM是CMMI的前⾝，⽽CMMI V1.1虽然⽐CMM要新很多，但现在已经不⽤了。
现在在互联⽹上还有很多⽐较CMM与CMMI的⽂章的，除⾮你很想了解或者你有很多时间，建议不必去看这些内容。
举一个通俗的例子来说明CMMI的级别
CMMI等级一共分5级，分别是：CMMI 1初始级CMMI 2管理级CMMI 3可定义级CMMI 4量化级CMMI 5持续改进级下面就具体讲这5个级别，CMMI 1初始级了解了CMMI的身世，我们再来看一下CMMI的不同级别。
严格来讲，CMMI级别有连续式和阶段式两种描述方式。
虽然方式不同，但所表达的意思是一样的。
我们以最常用的阶段式进行描述。
先来看下边这个故事：某公司刚刚拿到一笔订单，某公司让小张主要负责开发这个项目。
小张是名牌大学毕业高材生，一个人可以几天几夜不休息写出几千行代码，在某公司属于大侠级人物。
接到上司的任务，小张不敢怠慢，仔细阅读了项目合同，并和用户方通了电话，仔细询问了用户希望实现的需求。
经过一番深思熟虑，他的脑海里已经有了大概的构思。
于是，小张打开电脑，开始了他非常熟悉的编码工作。
一周过去了，老板过来询问项目的进展，小张说如果不出意外的话，一个月应该差不多能完成。
老板很高兴，夸奖小张很能干。
可接下来的事情并不像小张想象的那么顺利，他突然发现：由于一时疏忽，竟然忘掉了一个很重要的功能；如果将其加进去，需要推翻以前编写的大部分代码。
想到已经跟老板夸下海口，没有办法的小张只好连续加班好几个晚上，最后终于把代码修改完成了。
虽然经过了这样一次挫折，但是小张感觉还是比较庆幸：幸亏自己发现得早，要不然就死定了。
接下来的开发一切顺利，小张还是重复着夜以继日的编码工作。
眼看就要大功告成，小张很高兴得把喜讯告诉了老板，于是老板也很高兴得通知了客户，说下周你们就可以过来看产品了。
用户高高兴兴来到公司之后，当小张跟他们介绍产品时，用户却挑出了很多毛病。
原来小张当初没有完全理解用户的意图，此后也没有与用户进行太多沟通，他以为自己已经完全理解了用户需求，因此就按照心目中的想像把产品开发完成了。
看到用户提的那么多问题，小张别无选择。
于是，他又开始没日没夜地修改起了代码。
这次小张吸取上次的教训，跟用户进行了多次沟通，最后终于完成了产品。
CMMI的五个级别及其特征简述
CMMI的五个级别及其特征简述
CMMI 一共分五个级别，一级最低，五级最高，一般企业初次认证CMMI从三级开始。
1、CMMI一级，完成级。
在完成级水平上，企业对项目的目标与要做的努力很清晰。
项目的目标得以实现。
一般来说，公司的初始阶段就是一级，所以一级不需要认证。
2、CMMI二级，管理级。
在管理级水平上，企业在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对相关的项目实施人员有相应的培训，对整个流程有监测与控制，并与上级单位对项目与流程进行审查。
二级认证要求企业有一套简单的流程，一般规范的企业基本都可以达到。
3、CMMI三级，定义级。
在定义级水平上，企业不仅仅能够对项目的实施有一整套的管理措施，并保障项目的完成；企业能够根据自身的情况以及自己的标准流程，将这套管理体系与流程予以制度化。
三级认证有一套完整的流程，所以对一般企业来说，三级是软件企业最好的选择。
4、CMMI四级，量化管理级。
量化管理级分析对软件工程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制，管理有一个做出结论的客观依据。
5、CMMI五级，优化级。
优化管理级的量化反馈和先进的新思想、新技术促使过程持续不断改进。
企业不仅能够通过信息手段与数字化手段来实现对项目的管理，而且能够充分利用信息资料，对企业在项目实施的过程中可能出现的次品予以预防。
能够主动地改善流程，运用新技术，实现流程的优化。
CMMI的五个等级
的环境，它的成功依赖于组织中个人的能力和英雄主义，而不是依赖于 使用经过验证的过程
尽管这种混乱、无序的环境，处于初始级别的组织也经常能制造出能工
作的产品和服务，但是，他们的项目经常是超成本和进度的
处于初始级的组织有过度承诺的趋势，在危机时放弃过程，不能重复他
Managed
项目基本管 理
项目监督和控 制 PMC 项目计划 PP 供应商合同管 理 SAM
需求管理 REQM
过程和产品质量保证 PPQA 配置管理 CM 度量和分析 MA
集成项目管理 IPM
Defined
组织过程焦点 OPF
组织过程定义 OPD
需求开发 RD 技术解决方案 TS
决策分析和解决方案 DAR
ML4-ML5
ML5：优化级
ML3-ML4
ML4：定量管 理级
定量项目管理 组织过程性能 度量和管理
组织流程 产品开发工程 项目管理 支持工程
建立预防文化，具 备更加客观和准确 的控制能力
建立共享文化，开 放层次、方法和手 段；形成协同能力 如何建立一个质量 文化—遵守流程的 文化
ML2-ML3
ML3：定义级
组织级过程 定义
风险管理 RSKM
组织培训 OT
产品集成 PI
验证 VER 确认 VAL
Quantitatively 侧重量化和 预防 Managed
量化项目管理 QPM
组织过程性能 OPP 组织改革和实施 OID 原因分析和解决方案 CAR
Optimizing
持续改进
成熟度1级的特性: Initial
度量分析Measurement and Analysis（MA） 产品与过程质量保证Product and Process Quality Assurance（PPQA） 配置管理Configuration Management（CM）
CMMI将能力成熟度分为5个级别
21.OID：(OrganizationalInnovationandDeployment）组织的创新与推展，选择并推展渐进创新的组织过程和技术改善，改善应是可度量的，所选择及推展的改善需支持基于组织业务目的的质量及过程执行目标。
22.CAR：（CausalAnalysisandResolution），识别缺失的原因并进行矫正进一步的防止未来再次发生。
度量分析Measurement and Analysis
过程和产品质量保Process and Product Quality Assurance支持证
配置管理
第3级
已定义级需求开发
技术方案Configuration Management
Requirements Development
Technical Solution支持工程工程11个过程域产品集成
19.OPP：（OrganizationalProcessPreformace）组织过程性能。建立与维护组织过程性能的量化标准，以便使用量化方式的管理项目。20.QPM（QuantitativeProjectManagement)量化的项目管理，量化管理项目已定义的项目过程，以达成项目既定的质量和过程性能目标。。
风险管理Risk Management
决策分析与解决方Decision Analysis and Resolution
案
第4级组织过程绩效Organizational Process Performance
Quantitative Project Management过程管理项目管理量化管理级定量项目管理
验证
确认
组织过程焦点
组织过程定义
CMMI的5个级别和25个过程域
CMMI全称是Capability Maturity Model Integration，即软件能力成熟度模型集成模型。
分为5个级别，25个过程域（Process Area，PA）。
1、初始级（Initial）软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。
管理是反应式的。
2、可重复级/受管理级（Repeatable）建立了基本的项目管理过程来跟踪费用、进度和功能特性。
制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。
共7个过程域：1）需求管理Requrements Management2）项目规划Project Planing3）项目跟踪和控制Project Monitoring and Control4）供应商协议管理Supplier Agreement Management5）度量与分析Measurement and Analysis6）过程与产品质量保证Process and Product Quality Assurance7）配置管理Configuration Management3、已定义级（Defined）已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。
所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。
共14个过程域：1）需求开发Requirements Development2）技术解决方案Techical Solution3）产品集成Product Integration4）验证Verification5）确认Validation6）组织过程焦点Organization Process Focus7）组织过程定义Organization Process Defintion8）组织培训Orgnizational Training9）集成项目管理Integrated Project Management10）风险管理Risk Management11）决策分析和解决DecisionAnalysis and Resolution12）集成团队Integrated Teaming13）集成组织环境Organizational Environment for Integration14）集成供应商管理Integrated Suppliers Management其中12、13是针对大型软件团队提出的要求，一般情况下中小型软件企业可以不用。
CMMI的5个级别和25个过程域
CMMI的5个级别和25个过程域CMMI (Capability Maturity Model Integration)是一个结构化的过程改进方法，用于评估和提升组织的软件工程能力。
CMMI分为五个不同的成熟度级别，每个级别都有一组相关的过程域。
本文将详细介绍CMMI的五个级别和25个过程域。
1. 初始级别 (Level 1 - Initial)初始级别指的是一个组织在软件开发方面缺乏组织化和预测性的过程。
在这个级别上，软件开发过程通常是不可控制的，且无法重复使用。
这意味着项目结果无法预测和控制，导致成本和进度的不确定性。
2. 执行级别 (Level 2 - Managed)执行级别指的是一个组织开始建立和管理自己的软件开发过程。
在这个级别上，组织已经建立了一些基本的软件开发过程，并能够在不同的项目中重复使用这些过程。
然而，这些过程还没有得到完全的规范和标准化。
2.1 需求管理 (Requirements Management)需求管理是确保正确、一致和可追踪需求的过程。
它涉及定义、确认和维护需求，以确保项目能够满足用户的期望。
2.2 项目计划与监控 (Project Planning and Monitoring)项目计划与监控是制定和监控项目时间表、成本和资源的过程。
它确保项目能够按计划进行，并能够做出合适的调整以达到预期的目标。
2.3 供应商协商 (Supplier Agreement Management)供应商协商是与供应商建立和维护合作关系的过程。
它确保与供应商的交付和管理能够满足项目的需求。
2.4 产品质量保证 (Product Quality Assurance)产品质量保证是确保项目交付的产品符合质量标准和用户期望的过程。
它涉及质量计划、质量审查和质量度量等活动。
2.5 配置管理 (Configuration Management)配置管理是管理项目的配置项（包括软件、硬件和文档等）的过程。
CMMI基础知识4-5级
企业的商业目标
保持一定质量水平的情况下，提高生产 率，即每投入1分钱，带来更大的收益。
完成相同规模的项目，需要更短的时间， 更低的成本。
每投入1分钱，能提高更多的质量。
12
我们公司的商业目标
公司力争在三年内成为国内领先的软件 公司之一。
公司近期的重点是保持“华微电力智能 巡检系统”这个产品的技术和市场竞争 力，并以之为核心形成供电企业生产管 理系统，参与全国范围内的市场竞争。
由于现阶段系统更新比较频繁，为了不影响客户的工作， 希望不要在客户上班时间对系统进行更新。
系统每次作出更新后，请给客户发邮件说明更新的功能。
处置办法：
此问题只能在往后实施时谨慎注意. 建议先在客户处测试环境部署一次,并记下每次修改,这样
13
商业目标分解
提高竞要有保证 4. 价钱合理 5. 要按期完成
14
影响我们商业目标的问题曾经有：
预算不准，持续增大！ CPI偏低！ 不知道客户的满意度情况！ 没有信心软件是否充分测试！ 需求调研工作质量不太能保证！ 设计过程质量差！ 编码漏洞多！
18
例子 2005-8的一份报告 -2
1.3改进目标
加强预算的控制，减小预算的波动。 提高需求、设计工作的质量。 建立客户满意度的度量体系，提高客户满
意度。
1.4时间要求
要求2005年年度内实现改进目标。
19
例子 2005-8的一份报告 -3
性能参数
限值
当前值
成本指数(CPI) 平均值上限 109.76%
到比四级更“离谱”呢？
两人一组讨论，3分钟
6
CMMI4级遗留的问题
何总的疑问：项目还不够类似，还不是 很准？
如何理解CMMI的五个级别
CMMI的五个级别如何理解呢？我来做个类比。
大家都学过社会发展简史，人类社会经历了原始社会、奴隶社会、封建社会、资本主义社会，还有马克思预言的共产主义社会。
CMMI五个级别分别与人类社会的五个形态有类似之处。
CMMI一级如同原始社会。
在原始社会，没有法律、没有制度，部落间发生冲突和相互仇杀是常有的事情。
在CMMI一级的组织，产品开发没有规矩，每个人的工作方式全凭喜好和习惯，一般项目中也极少有关于过程方面的规定，不论采用什么方法、遵循什么样的开发步骤，最后只要把代码写出来了就可以了，软件开发的主要活动就是编码和调试。
很少有项目计划，顶多有个项目时间表，需求、设计等工程文档也很少有。
CMMI二级如同中国的奴隶社会。
从奴隶社会开始，人类便有了文字记载的历史，出现了法律法规，人类进入文明时代，夏、商、周、春秋战国都属于奴隶社会。
但中国的奴隶社会国家，实际上是由众多的诸侯国构成，每个诸侯国有自己法律、度量衡、货币、语言、文字等。
处于CMMI二级的组织，各个项目（好比诸侯国）有了各自的制度和标准，比如项目A规定采用瀑布开发模型，使用CVS作为配置管理工具，要度量项目的进度和成本；而项目B规定采用增量开发模型，使用VSS作为配置管理工具，度量项目的质量成本和需求稳定度。
同CMMI一级比，项目的开发过程已由混乱的开发方式跃迁到了有纪律的开发过程。
公元前221年，秦始皇统一全国，从此中国开始步入了封建社会。
秦始皇不仅仅统一了领土，更具有长远意义的是他统一了法律、文字、货币和度量衡。
在秦之前的诸侯割据时代，文字的不统一严重影响文化传播和交流，货币制的不统一，也严重阻碍着各地商品的流通及统一国家的财政收支，其它方面的不统一也同样带来各种各样的问题。
文字、货币、度量衡的统一，在中国历史上占有重要地位。
孔子之孙子思在《中庸》倡导“今天下，书同文、车同轨、行同伦”，可见统一的、标准化是多么重要，如同工业上零件规格的统一，或网络协议的统一一样，都有着重要。
CMMI的5个等级记忆法(夏娃法与路法)_菜头
CMMI的5个等级：
亚当夏娃法
1.初始级：亚当和夏娃初尝禁果，动作还比较生涩；
2.可重复级：随着OOXX的次数增加，亚当和夏娃动发现了几个让他们觉得
很Hight的动作，他们每次都会用上这几个动作，形成规范和制度；
3.已定义级：亚当和夏娃的经验逐渐丰富，从以往OOXX中总结经验，并形
成了标准的规程向其它人推广，例如：老汉推车，观音坐莲等套路。
4.管理级：因为和其它人相互学习，水平不断提高，每次OOXX的过程质量
稳定。
亚当和夏娃总结了每个动作Hight的程度，建立OOXX过程模型，每个动作可以加特定分数，达到量化预测OOXX质量的水平。
5.优化级：亚当和夏娃在进步中也不断的碰到新的问题，偶尔也会觉得不爽。
在做好管理级的基础上，循序渐进的进行动作创新和过程改善，找寻不爽的根本原因，例如加强前戏和事后关怀，系统地、持续地改进OOXX的能力与质量。
路法
就跟路是怎么来的原理是一样。
(From 重庆苍龙(6184368))
初始：世上本没有路，
重复：走的人多了，就有路了。
定义：定义什么是人走的路。
管理：路多了，我们规范管理，什么是人走的路，什么是车走的路。
优化：路面由泥巴路变成水泥路。
CMMI的五个等级
我公司实施CMMI 3关注重点 我公司实施CMMI 3关注重点
服务于商业目标的报告流程(Reporting 服务于商业目标的报告流程(Reporting procedure) 建立公司统一的管理和开发流程(OSSP) 建立公司统一的管理和开发流程(OSSP) 过程改进有公司级的组织保证(EPG) 过程改进有公司级的组织保证(EPG) 软件工程的生产活动有明确的流程和标准 项目管理和工程活动得到集成 建立科学合理的决策流程(Decision 建立科学合理的决策流程(Decision making procedure) 更好地控制风险 建立组织过程资产库(包括度量数据) 建立组织过程资产库(包括度量数据)为后续项目使用
CMMICMMI-DEV ML2 PAs
需求管理 Requirement Management（REQM） Management（REQM） 项目计划Project Planning（PP） 项目计划Project Planning（PP） 项目跟踪与控制Project 项目跟踪与控制Project Monitoring and Control（PMC） Control（PMC） 供应商合同管理Supplier 供应商合同管理Supplier Agreement Management（SAM） Management（SAM） 度量分析Measurement 度量分析Measurement and Analysis（MA） Analysis（MA） 产品与过程质量保证Product 产品与过程质量保证Product and Process Quality Assurance（PPQA） Assurance（PPQA） 配置管理Configuration Management（CM） 配置管理Configuration Management（CM）
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将能力成熟度分为5个级别
CMMI将能力成熟度分为5个级别：初始级，已管理级，已定义级，量化管理级，优化级。
这5个成熟度等级为评价软件过程能力提供了一个有序的级别，如图5-10所示。
同时也为软件过程改进工作指明了方向，让人们分清轻重缓急，指导人们一步一步地改进过程能力而不是企图跳跃式地前进。
1初始化-->2.已管理级-->3.已定义级-->4.量化管理级-->5.优化级除了成熟度等级，CMMI还有一个重要的概念是过程域(Process Area)。
过程域指出了达到某个成熟度等级必须要解决的一族问题。
除了初始级以外，每个成熟度等级都有若干个过程域，如表5-1所示。
由于成熟度等级是循序渐进的，如果想达到某个成熟度等级，例如CMMI 3级，除了满足CMMI 3级本身11过程域之外，还要满足CMMI 2级的7个过程域，依此类推。
、过程管理:1. OPD :(Organizational Process Definition)组织级过程定义。
建立和维护有用的组织过程资产2. OPF：(Organizational Process Focus)组织级过程焦点。
在理解现有过程强项和弱项的基础上计划和实施组织过程改善3. OT ：(Orga nizatio nal Trai ning)组织培训管理。
增加组织各级人员的技能和知识，使他们能有效地执行他们的任务。
二、项目管理：4. PP：( Project Plan)项目计划。
保证在正确的时间有正确的资源可用。
为每个人员分配任务。
协调人员。
根据实际情况，调整项目。
5. PMC： ( Project Monitoring and Control)项目监督与控制。
通过项目的跟踪与监控活动，及时反映项目的进度、费用、风险、规模、关键计算机资源及工作量等情况，通过对跟踪结果的分析，依据跟踪与监控策略采取有效的行动，使项目组能在既定的时间、费用、质量要求等情况下完成项目。
6. SAM：(Supplier Agreement Managemen)t 供应商协议管理。
CMMI将能力成熟度分为5个级别
CMMI将能力成熟度分为5个级别：初始级，已管理级，已定义级，量化管理级，优化级。
这5个成熟度等级为评价软件过程能力提供了一个有序的级别，如图5-10所示。
同时也为软件过程改进工作指明了方向，让人们分清轻重缓急，指导人们一步一一、过程管理：1．OPD：（Organizational Process Definition）组织级过程定义。
建立和维护有用的组织过程资产。
2．OPF：（Organizational Process Focus）组织级过程焦点。
在理解现有过程强项和弱项的基础上计划和实施组织过程改善。
3．OT：（Organizational Training）组织培训管理。
增加组织各级人员的技能和知识，使他们能有效地执行他们的任务。
二、项目管理：4．PP：（Project Plan）项目计划。
保证在正确的时间有正确的资源可用。
为每个人员分配任务。
协调人员。
根据实际情况，调整项目。
5．PMC：（Project Monitoring and Control）项目监督与控制。
通过项目的跟踪与监控活动，及时反映项目的进度、费用、风险、规模、关键计算机资源及工作量等情况，通过对跟踪结果的分析，依据跟踪与监控策略采取有效的行动，使项目组能在既定的时间、费用、质量要求等情况下完成项目。
6．SAM：（Supplier Agreement Management）供应商协议管理。
旨在对以正式协定的形式从项目之外的供方采办的产品和服务实施管理。
7．IPM：（Integrated Project Management）集成项目管理。
根据从组织标准过程剪裁而来的集成的、定义的过程对项目和利益相关者的介入进行管理。
8．RSKM：（Risk Management）风险管理。
识别潜在的问题，以便策划应对风险的活动和必要时在整个项目生存周期中实施这些活动，缓解不利的影响，实现目标。
三、工程管理:9．RD：（Requirement Development）需求开发。
cmmi五个成熟度级别
CMMI 等级的含义五个成熟度级别之间的比较如下:1,初始级特征:(1)软件过程的特点是杂乱无章,有时甚至混乱.几乎没有定义过程的规则或步骤.(2)过分的尽诺.常做出良好的承诺:如"按照软件工程方式,有序的工程过程来工作";或达到高目标的许诺.但实际上却出现一系列危机.(3)遇到危机就放弃原计划过程,反复编码和测试.(4)成功完全依赖个人努力和杰出的专业人才,取决于超常的管理人员和杰出有效的软件开发人员.具体的表现和成果都源于或者说是决定于个人的能力和他们先前的经验,知识以及他们的进取心和积极程度.(5)能力只是个人的特性,而不是开发组织的持性.依靠着个人的品质或承受着巨大压力,或找窍门取得成果.但此类人一旦离去,对组织的稳定作用也消失.(6)软件过程是不可确定的和不可预见的.软件成熟性程度处于第一级的软件组织的软件过程在实际的工作过程中被经常的改变(过程是随意的).这类组织也在开发产品,但其成果是不稳定的,不可预见的,不可重复的.也就是说,软件的计划,预算,功能和产品的质量都是不可确定和不可预见的.过程:(1)极少存在或使用稳定的过程.(2)所谓"过程",往往是"就这么干"而言. (3)各种条例,规章制度互不协调,甚至互相矛盾人员:(1)依赖个人努力和杰出人物.一旦优秀人物离去,项目就无法继续(2)人们的工作方式如同"救火".就是在开发过程中不断地出现危机,以及不断的"救火".技术: 引进新技术是极大风险度量: 不收集数据或分析数据改进方向:(1)建立项日管理过程.实施规范化管理.保障项目的承诺.(2)首要任务是进行需求管理,建立客户与软件项目之间的共同理解,使项目真正反映客户的要求.(3)建立各种软件项目计划.如软件开发计划,软件质量保证计划,软件配置管理计划,软件测试计划,风险管理计划及过程改进计划.(4)开展软件质量保证活动(SQA).2,可重复级特征(1)进行较为现实的求诺,可按以前在同类项目上的成功经验建立的必要过程准则来确保再一次的成功.(2)主要是逐个项目地建立基本过程管理条例来加强过程能力.(3)建立了基本的项目管理过程来跟踪成本,进度和功能.(4)管理工作主要跟踪软件经费支出,进度及功能.识别在承诺方面出现的问题.(5)采用基线(BASELINE)来标志进展,控制完整性.(6)定义了软件项目的标准,并相信它,遵循它.(7)通过于合同建立有效的供求关系.过程(1)软件开发和维护的过程是相对稳定的,但过程建立在项目一级.(2)有规则的软件过程是在一个有效的工程管理系统的控制之下,先前的成功经验可以被重复.(3)问题出现时.有能力识别及纠正.其承诺是可实现的.人员(1)项目的成功依赖于个人的能力以及管理层的支持.(2)理解管理的必要性及对管理的承诺.(3)注意人员的培训问题, 技术建立技术支持活动,并有稳定的计划. 度量每个项目建立资源计划.主要是关心成本,产品和进度.有相应的管理数据.改进方向(1)不再按项目制定软件过程,而是总结各种项目的成功经验,使之规则化,把具体经验归纳为全组织的标准软件过程.把改进组织的整体软件过程能力的软件过程活动,作为软件开发组织的责任.(2)确定全组织的标准软件过程,把软件工程及管理活动集成到一个稳固确定的软件过程中.从而可以跨项目改进软件过程效果,也可作为软件过程剪裁的基础.(3)建立软件工程过程小组(SEPG)长期承担评估与调控软件过程的任务,以适应未来软件项目的要求.(4)积累数据:建立组织的软件过程库及软件过程相关的文档库(5)加强培训.3,确定级特征：(1)无论管理方面或工程方面的软件过程都已文件化,标准化,并综合成软件开发组织的标准软件过程.(2)软件过程标准被应用到所有的工程中,用于编制和维护软件.有的项目也可根据实际情况,对软件开发组织的标准软件过程进行剪裁.(3)在从事一项工程时,产品的生产过程,花费,计划以及功能都是可以完全控制的,从而软件质量也可以控制.(4)软件工程过程组(SEPG)负责软件过程活动.(5)在全组织范围内安排培训计划.过程：(1)整个组织全面采用综合性的管理及工程过程来管理.软件工程和管理活动是稳定的和可重复的,具有连续性的.(2)软件过程起了预见及防范问题的作用,能使风险的影响最小化人员：(1)以项目组的方式进行工作.如同综合产品团队.(2)在整个组织内部的所有人对于所定义的软件过程的活动,任务有深入理解.大大加强了过程能力.(3)有计划地按人员的角色进行培训技术在定性基础上建立新的评估技术.度量：(1)在全过程中收集使用数据.(2)在全项目中系统性地共享数据改进方向(1)开始着手软件过程的定量分析,以达到定量地控制软件项目过程的效果.(2)通过软件的质量管理达到软件的质量目标.4,管理级特征：(1)制定了软件过程和产品质量的详细而具体的度量标准.软件过程和产品的质量都可以被理解和控制.(2)软件组织的能力是可预见的.原因是软件过程是被明确的度量标准所度量和操作.不言而喻.软件产品的质量就可以预见和得以控制.(3)组织的度量工程保证所有项目对生产率和质量进行度量,并作为重要的软件过程活功.(4)具有良好定义及一致的度量标服来指导软件过程,并作为评价软件过程及产品的定量基础.(5)在开发组织内已建立软件过程数据库,保存收集到的数据,可用于各项目的软件过程. 过程：(1)开始定量地认识软件过程.(2)软件过程的变化小.一般在可接受的范围内.(3)可以预见软件过程中和产品质量方面的一些趋势.一旦质量经度量后超出这些标准或是有所违反.可以采用一些方法去改正,以达到良好的日标.人员：每个项目中存在强烈的群体工作意识,因为每人都了解个人的作用与组织的关系,因此能够产生这种群体意识. 技术不断的在定量基础上评估新技术.度量：(1)在全组织内进行数据收集与确定.(2)度量标准化.(3)数据用于定量地理解软件过程及稳定软件过程.改进方向：(1)缺陷防范.不仅仅在发现了问题时能及时改进,而且应采取特定行动防止将来出现这类缺陷.(2)主动进行技术变动管理,标识,选择和评价新技术.使有效的新技术能在开发组织中施行,(3)进行过程变动管理.定义过程改进的目的,经常不断地进行过程改进.5,优化级特征：(1)整个组织特别关注软件过程改进的持续性,顶见及增强自身.防止缺陷及问题的发生.不断地提高他们的过程能力.(2)加强定量分析,通过来自过程的质量反馈和吸收新观念,新科技,使软件过程能不断地得到改进,(3)根据软件过程的效果,进行成本/利润分析,从成功的软件过程实践中吸取经验,加以总结.把最好的创新成绩迅速向全组织转移.对失败的案例,由软件过程小组近行分析以找出原因.(4)组织能找出过程的不足并预先改进.把失败的教训告知全体组织以防止重复以前的错误.(5)对软件过程的评价相对标准软件过程的改进,都在全组织内推广.过程：(1)不断地系统地改进软件过程(2)理解并消除产生问题的公共根源.在任何一个系统中都可找到:由于随机变化造成重复工作,进而导致时间浪费.为了防止浪费人力可能导致的系统变化.要消除"公共"的无效根源,防止浪费发生.尽管所有级别都存在这些问题,但这是第五级的焦点.人员：(1)整个组织都存在自觉的强烈的团队意识.(2)每个人都致力于过程改进.人们不再以达到里程碑的成就而满足,而要力求减少错误率. 技术基于定量的控制和管理,事先主动考虑新技术,追求新技术,利用新技术.可以实现软件开发中的方法和新技术的革新,以防止出现错误,不断提高产品的质量和生产率.度量：利用数据来评估,选择过程改进. 改进方向保持持续不断的软件过程改进.二,敏捷开发和高级别CMMI 关键字:高级别CMMI 敏捷开发我经常和别人一起讨论敏捷开发过程的知识,并且我们也会经常争论结合使用敏捷开发过程和CMMI 高级别的话题.他们两个是否能够结合使用?或者他们两个只是向相反的方向发展?带着这个疑问,下面我们一起来探讨. "这个问题可以说是老生常谈,但是我对第 5 级别中的那个基本差异有一个疑问,这个疑问会使人产生不安的情绪.CMMI1.2 强调了想在组织中控制结果的变更, 进而将其重心转移到了个人的身上.敏捷开发在意义上说不单单是为了让每个项目能在应对各种各样的环境中都拥有灵活的能力,并且可以让他们在这个环境中尽其所能表现的最好.我们并没有特别关注在所有项目中要规范行为以便可以预知结果是"可靠的". 但是,我并不清楚我现在尽力想说明的这种区别,是否确实是敏捷开发和CMMI 的基本概念中的一个基础的区别,还是只是组织如何解释和执行CMMI 第 5 级别的一个结果.当然,敏捷开发团队在过程模型和过程实践资产中拥有的信任似乎要比CMMI 团队中的要少――虽然在敏捷中没有方法可以规范这些事情即便他们是低成本的,但是没有假设说明这就是组织要走的路.事实上,敏捷开发支持者偏向于这样的想法, 在任何形式的可遇见的过程模型中快速地建立起逐渐减少的成果.是否这就是等同说敏捷开发支持者相信特殊原因会影响执行效果是如此的普遍,以至在组织中试图建立预见性的模型是无用的?" CMMI 第4 级别: QPM(量化项目管理):主要关注懂得过程行为变更的个别项目,他们认为这些变更影响着他们的成功和如何处理事情――或者至少影响着完成产品发展或者达成目标.组织单位(EPG)必须要监控成果. OPP(组织过程实践):主要关注集成模型,项目可以使用模型来规范他们想要达到成功的方面,比如说质量,进度表,预算,维护以及其他任何事情.诀窍就是项目在过程执行中以这些模型为基础,控制QPM 中的行为.比较典型的是,这些模型可能是基于相似的项目中的重复的结果不断建立起来的,虽然可能并没有这样的需求. 在个别项目级别中模型应该先被改进以便使用,所以在CMMI 模型中使用基于一个项目的历史数据(比如说,增量)或者20 个项目的历史数据是没有区别的,虽然这可能对使用者来说是有区别的. CMMI 第5 级别: CAR(原因分析与解决方法):主要关注引起问题的主要原因,过失,管理问题或者其他一切需要解决的问题.项目,EPG 或者其他任何人是否可以应用,是作为解决问题的方法.EPG 在OPP 中监控结果,或者得到别的经验.(敏捷开发是否在增量开始点或者结束点不建议进行类似的行为?我不清楚我所知道的术语是否正确) OID(组织创新与推展):完全非项目特点.关注基于个体,CAR,模型使用,外界因素等的组织改进.你是否会收集并且使用所有这些学到的经验?你进入企业后是否会寻求新的或者更好的做生意的方法(其中敏捷开发可能只是一个例子)?在组织中又该如何处理证明,分析(职业),和使用(结构请参照第 4 级别中的模型和过程控制)这些改进. 我个人认为CMMI 高级别和敏捷开发应该结合起来工作.敏捷可以帮助CMMI 高级别更容易实现短期的转变,并且它在处理事情的发展上起了很重要的作用.我的经验基本是从第5 级别得来的,有部分来自第4 级别.许多组织怀着"每个人都必须如此做"的想法而通过了第3 级别,但是他们却反对在第4,5 级别中有着同样的想法.就像我曾经提到的,敏捷开发是使用CMMI 第4,5 级别来改进如何发展产品的完美例子. CMMI 是Capability Maturity Model Integration(能力成熟度模型集成)的缩写, 是在CMM(Capability Maturity Model 能力成熟度模型)的基础上发展而来三,CMMI 实施现在很多企业因某种原因想做CMMI 了,大体做法1,决定实施CMMI 2,EPG 接受培训,理解CMMI 3,EPG 根据自己理解的CMMI 和实际情况开发一大堆漂漂亮亮的过程文档,流程图,表格,模板,检查单,作业指南. 4,大家边听着EPG 的解释(包括培训,答疑),边执行这些过程标准,然后审计(内,外) 将目前的最佳实践记录下来,写下来,文档化下来. 很多新的EPG 在做了一段时间后无奈的发现自己居然沦落成了一个过程标准解说员,甚至文档管理员.自己工作大部分时间是面对文档,或者督促别人写文档我到觉得EPG 最主要的工作应该深入到研发第一线,帮助研发人员解决研发过程中面临的最严重的实际问题(当然是解决方案要上升到过程高度,而不应是单个问题或个人),甚至哪怕是一些不严重但以你的项目经验知道该如何解决的问题上.总体说来就是掌握项目进展中的任何细微的技术难点要点,并主动记录下来. 为什么这么说呢?CMMI 实施的主要宗旨就是以每个项目为采集数据的源头,达到企业整体效益提升和资源重用.真正有价值的东西,是需要一线人员在实际工作中遇到问题,解决问题,并总结问题,不是一个一线工作的流水帐.就象一份研发人员的日报.写了上午做什么,下午做什么.这对企业的积累有什么用处呢?他工作过程中, 遇到什么问题,他是怎么解决的,走过什么弯路,实验过几种方法,失败了,失败的原因是什么,最后选择了什么方法,可能不是最好的,但完成了任务,达到了效率和资源分配的平衡.这些东西才可能是未来类似项目中,遇到类似问题时,可能有参考价值的.通常也是EPG 个人职业生涯的技术积累.只有公司里每个员工,把自己认为最有价值的积累贡献出来.才可能达到公司有价值的积累.而决不是形式上写的上午下午每个小时的流水帐. 明白了上面的说的CMMI 的目的,做为一个合格的EPG,就应该具备以下的素质: 1,明白什么是有价值的积累,先是对你个人,然后才是顺便帮公司做了积累. 2,深入一线,发现她们并忠实地记录她们.CMMI 里的SP,GP,只是帮助你,提醒你在哪个环节,哪些东西可能是有价值了.你去收集一下,别视而不见了.因为还有一个企业和你个人的角度不同,立场不同的问题.例如,REQM 里收集需求,对个人技术方面的积累虽然不多,但对企业是至关重要的,一次需求变更,没详细写清楚, 忘记了到客户那里去签字落实,可能就会给企业造成很大的损失.做为一个合格的EPG,是需要有这份责任和义务把每个环节都做到最好,这是职业道德所在.同时也是对自我延伸的一个好机会,学会一些和人的沟通,倾听,把专业的东西以平易的方式表达.这些也都算是EPG 额外的收获. 通常情况下,为了按时按量完成项目,一线的骨干,对写日报,周报,文档都很不屑.EPG 也很迁就,事后再补,这也不失为一个提高效率的好办法.但过去一个月半年了,我们正常人的记忆都能想象,很难记住细节.无非就是敷衍.这也在情理之中.你总不能让一个明天就要交东西的小组,今天晚上在通宵努力解决BUG 的同时, 还写什么报告,这也不尽人情.但作为EPG 不能只把眼光集中在这妇人之心上.要想的更远.为什么会把项目推到这么晚,BUG 还没解决完?难道要永远这样下去吗?项目中是有很多不可预测的因素,甚至是开发人员常说的"手气问题","人品问题".但这些是需要控制的,也是通过经验可以控制的,所谓艺高人胆大.艺的高低,就是经验的积累决定的. 那怎么解决这种两难的问题呢?逼着技术骨干写心水,人家没时间也的确压力很大.不写,公司又得不到有效积累,积累的都是垃圾流水.有个公司的办法和经验到可以借鉴一下: 公司内部搞了个BBS,把不同类型的工作分成不同的组,有纯技术的,JAVA 组, C++组等,也有PPT 组,甚至动画组,界面组.大家把自己平时的工作积累FTP 上去,甚至制作方法,遇到问题和解决方法的文档都丢上去,开始怎么想,用了多少套方案,最后选择了什么.自我感觉如何.把这些心路历程都写成文档.丢到阳光下, 大家评论.用点击率和"顶"的人数来说明谁写的是心水,谁在写垃圾.大家都是一个公司的,很容易实名.直接纳入考核机制中.做为一线人员,大家也有动力来写,自己的聪明才智有了展现的平台,虚荣心和荷包都得到了相应的满足.何乐而不为呢? EPG 适时的评估大家的成果,并把他们分到项目里.帮助项目总结,甚至在平时遇到问题时,直接帮助技术人员做必要记录.项目进度松时,再督促项目人员完善内容.以达到对个人和公司积累的最大化. EPG 应该明白学习和积累是个终身的过程,对公司如此,对个人也是如此.CMMI 是个辅助,辅助我们对公司做积累,也帮助我们个人做必要的积累.公司需要逐步走向更高的管理水平,发展平台. 四,CMMI 实施之核心关键字:CMMI,SCAMPI,过程改进,能力成熟度,EPG,PA,过程域在上一章节中,我们谈到了关于过程改进团队的组建方法及在组建过程中需要注意的问题,在本节中我们将继续探讨EPG 过程改进的另一个更为重要的一环——定义过程文档. 曾经有一位评估师开玩笑说,三级是写文档,四级是写文档的文档,五级是写文档的文档的文档.由此可见,文档贯穿于整个CMMI,在过程改进中起着举足轻重的作用.那么如何才能写出既符合CMMI 又立足于企业本身实际情况的文档呢?这就是本文将要探讨的问题——定义过程文档. 在定义过程文档时,首先,应该进行企业的习惯表述与CMMI 术语和语言间的映射.特别是组织结构中的一些术语,角色,组织内部之间关系以及过程活动的表述方式都需要映射到其组织的相应部分,以防止别人无法理解. 定义过程文档的一般步骤是: (1)先确定并描述产品的生命周期. 一般来说,产品生命周期可以划分为 6 个阶段,即产品概念阶段,产品定义阶段, 产品开发阶段, 产品测试阶段,用户验收阶段,产品维护阶段. (2)根据产品生命周期的各个阶段确定需要改进的过程域(PA)活动. "过程域"用于描述CMMI 标准定义的软件过程能力评估模型中的一种部件.在该模型中,"过程域"是最大的的构造块,每个"过程域"由一组目标构成,每个目标得到一组实践支持.模型中描述的过程是参考模板,用"过程域"来表示.不能与实际过程混淆."过程域"不是实际的过程,它是模型中的模板. (3)针对某一个PA 过程活动,完成PA 的数据流程图. (4)准备相应的模板,检查表或者方法附件定义过程文档.再在EPG 内部讨论修改,然后拿给评审人员阅读,最后是进行正式评审.进一步修订,再评审直到大家认可为止,再进入下一个PA 过程.(或者也可以评审通过后进行试点,试点成功再进入下有个PA 过程.) 根据自己多年的咨询经验,总结了在定义过程文档时一般容易出现的问题. 1,"本地化做得不够" 咨询顾问常常在项目进行中发现这样的问题:在定义某个PA 过程时,客户会过于依赖咨询公司提供的其他一些企业的过程文档,并将这些文档梢作调整成为其自己的过程文件.由于每个软件企业的情况是不一样,流程,规范,记录应该根据公司实际情况来制定,参照CMMI 框架,制定适合公司本身情况的"本地化"过程体系,这样的效果会更好. (2)总体把握,逐步细化在定义第一个PA 过程时,如果没有考虑它跟其它PA 之间的关系就直接参照CMMI 的此PA 的目标和实践完成了过程文件,可能发生的结果要么是无法通过评审, 要么就是通过了之后再返回进行修改.由于各PA 间关系密切,息息相关,因此在实际的定义过程中,先要从总体上把握住各PA 间关系,完成整个过程的数据流程图的基础上再进行逐步细分,否则即是"只见树木不见森林". (3)多交流,多总结由于在项目初期,EPG 小组对于CMMI 的理解不够透彻,大家也没什么经验,这就需要EPG 成员,QA,管理人员,开发人员之间多多交流,在定义过程文档时多讨论,集众人之智慧,随着过程定义的进展,EPG 小组对CMMI 的理解加深,就需要总结经验,避免将来在遇到类似问题的时候多走弯路.。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
CMMI的5个等级：
亚当夏娃法
1.初始级：亚当和夏娃初尝禁果，动作还比较生涩；
2.可重复级：随着OOXX的次数增加，亚当和夏娃动发现了几个让他们觉得
很Hight的动作，他们每次都会用上这几个动作，形成规范和制度；
3.已定义级：亚当和夏娃的经验逐渐丰富，从以往OOXX中总结经验，并形
成了标准的规程向其它人推广，例如：老汉推车，观音坐莲等套路。
4.管理级：因为和其它人相互学习，水平不断提高，每次OOXX的过程质量
稳定。
亚当和夏娃总结了每个动作Hight的程度，建立OOXX过程模型，每个动作可以加特定分数，达到量化预测OOXX质量的水平。
5.优化级：亚当和夏娃在进步中也不断的碰到新的问题，偶尔也会觉得不爽。
在做好管理级的基础上，循序渐进的进行动作创新和过程改善，找寻不爽的根本原因，例如加强前戏和事后关怀，系统地、持续地改进OOXX的能力与质量。
路法
就跟路是怎么来的原理是一样。
(From 重庆苍龙(6184368))
初始：世上本没有路，
重复：走的人多了，就有路了。
定义：定义什么是人走的路。
管理：路多了，我们规范管理，什么是人走的路，什么是车走的路。
优化：路面由泥巴路变成水泥路。