过程
(1)软件开发和维护的过程是相对稳定的，但过程建立在项目一级.
(2)有规则的软件过程是在一个有效的工程管理系统的控制之下，先前的成功经验可以被重复。
(3)问题出现时．有能力识别及纠正。其承诺是可实现的。
人员
(1)项目的成功依赖于个人的能力以及管理层的支持.
(2)理解管理的必要性及对管理的承诺。
(3)注意人员的培训问题，
技术
建立技术支持活动，并有稳定的计划。
度量
每个项目建立资源计划。主要是关心成本、产品和进度.有相应的管理数据.
改进方向
(1)不再按项目制定软件过程，而是总结各种项目的成功经验，使之规则化，把具体经验归纳为全组织的标准软件过程。把改进组织的整体软件过程能力的软件过程活动，作为软件开发组织的责任。
(2)确定全组织的标准软件过程，把软件工程及管理活动集成到一个稳固确定的软件过程中。从而可以跨项目改进软件过程效果，也可作为软件过程剪裁的基础。
(3)建立软件工程过程小组(SEPG)长期承担评估与调控软件过程的任务，以适应未来软件项目的要求。
(4)积累数据：建立组织的软件过程库及软件过程相关的文档库
(5)加强培训。
3、确定级
特征
(1)无论管理方面或工程方面的软件过程都已文件化、标准化，并综合成软件开发组织的标准软件过程。
(2)软件过程标准被应用到所有的工程中，用于编制和维护软件。有的项目也可根据实际情况，对软件开发组织的标准软件过程进行剪裁。
(3)在从事一项工程时，产品的生产过程、花费、计划以及功能都是可以完全控制的，从而软件质量也可以控制。
(4)软件工程过程组(SEPG)负责软件过程活动。
(5)在全组织范围内安排培训计划。
过程
(1)整个组织全面采用综合性的管理及工程过程来管理。软件工程和管理活动是稳定的和可重复的，具有连续性的。
(2)软件过程起了预见及防范问题的作用，能使风险的影响最小化
人员
(1)以项目组的方式进行工作。如同综合产品团队。
(2)在整个组织内部的所有人对于所定义的软件过程的活动、任务有深入理解。大大加强了过程能力。
(3)有计划地按人员的角色进行培训c
技术
在定性基础上建立新的评估技术。
度量
(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的解释(包括培训、答疑)，边执行这些过程标准，然后审计(内、外)
将目前的最佳实践记录下来、写下来、文档化下来。
[1] [2] [3] [4] [5] [6]
导航
