先讲讲需求管理的含义。
何谓需求管理？需求管理就是管理需求的一致性。
这里讲的需求指什么?指的产品与产品构件需求，对于软件而言通常就是软件需求规格说明书（SRS）。在CMMI模型中将需求分成了2类：客户需求，产品与产品构件需求。客户需求是采用用户的术语表达的，用户验收的依据，一般是由客户提出需求，由开发人员记录、描述、整理下来。客户需求是平衡了客户的需要、期望、约束和接口需求后的结果。产品与产品构件需求是采用开发人员的属于表达的，是开发方验收的依据。产品与产品构件的需求是基于客户需求派生而得到的，但是又并非仅仅基于客户需求，还可能由开发方附加了一些需求，还可能由于技术路线的实现约束而附件了一些需求。
谁和需求的一致性呢？用户需求、设计文档、代码、测试文档、用户手册、安装手册、项目计划书等文档。
在何时保证和需求的一致性呢？在需求开发的初期，在设计时，在编码时，在编写测试用例时，在编写用户手册时，在需求发生变更时，在设计、编码、测试用例、用户手册发生变更时！
需求管理是CMMI 2级中的唯一的一个工程类过程域，工程类过程域包括需求管理、需求开发、技术解决方案、产品集成、验证、确认，只有将需求管理放在了CMMI的2级，为什么呢？无论需求是如何获取的如何描述的，首先要管理需求的变更！这里隐含了一个前提，即需求是文档化的，需求管理的对象是需求，需求不能是虚无飘渺的，要固化下来，固化下来就是需求文档。
在此过程域中包含了5条特定实践，翻译如下：
SP1.1 理解需求：与需求的提供者对需求的含义达成一致
SP1.2 获得对需求的承诺：获得项目组成员对需求的承诺
SP1.3 管理需求的变更：在项目进行中，管理需求的变更
SP1.4 维护需求的双向可跟踪性：维护需求和工作产品之间的双向可跟踪性
SP1.5 确定项目工作和需求间的差异：识别项目计划、工作产品和需求之间的不一致
每条实践都有一个编号，以“SP1.3 管理需求的变更：在项目进行中，管理需求的变更”来说明一下，SP代表特定实践，1代表是第1个目标的实践，3代表是第3条实践。每条实践有一个名字，“管理需求的变更”即是这条实践的名字，“在项目进行中，管理需求的变更”是这条实践的正文。编号和名字都是解释性的信息，是帮助记忆的，每条实践的正文是“期望的”。
逐条解释每条实践：
SP1.1理解需求：与需求的提供者对需求的含义达成一致。
模型的每条实践都是动宾结构的描述方式，是没有主语的，我们在理解时要结合公司的实际情况，加上主语。对于这条实践，是谁与需求的提供者对需求的含义达成一致呢？是需求分析人员，是项目组的开发人员，是乙方。
需求的提供者是谁呢？是甲方，是客户、最终用户与间接用户。客户是出资者，是花钱买系统的人，最终用户是真正使用系统的人，间接用户是既不用系统也不掏钱买系统的，但是对系统是否上市、能否成功起了重要作用的人。举例来讲，你们家小孩需要买个手机，你是出资者、小孩子是最终用户、国家工信部是间接用户，三者的需求是不一样的，关注点是不同的。手机要既满足你的需求、小孩子的需求、政府的要求才可以销售出去。注意三者是and的关系，不是or的关系，缺一不可。
在CMMI中将需求分成了4个组成部分：需要，期望，约束条件和接口需求。需要是最基本的、不可裁剪的需求；期望是可以实现也可以不实现，最好能实现的需求，期望是可以妥协的需求；约束条件是对需要和期望的限制条件，是实现需要和期望的环境与障碍；接口需求是系统与其他系统之间的衔接关系，任何一个系统都不是孤立存在的。
何谓“一致”？是需求分析人员认可需求并且需求的提供者也认可了需求。仅仅是需求分析人员认可，需求提供者不认可，这显然是不成的，最终验收时肯定无法通过；仅仅是需求提供者一厢情愿，需求分析人员或者开发方不认可也是无法实现的。需求提供者关注什么？其一是正确性：是否准确表达了自己的需求？其二是完备性：是否遗漏了需求？开发人员关注什么？除了上述的正确性与完备性，还关注无二义性、可测试性、可实现性等等。
如何达成一致呢？通常是需求提供者（客户+最终用户+间接用户）讲解需求，需求提供者提供最初的需求，由需求分析人员整理需求，然后再给需求提供者确认需求，确认后一般是签字认可、邮件确认或体现在会议纪要中。
SP1.2 获得对需求的承诺：获得项目组成员对需求的承诺。
这条实践所讲的承诺是指对需求可实现性的承诺，是项目组成员对客户的承诺，承诺什么呢？是承诺需求是可以实现的。注意，这个承诺不是客户对项目组的承诺，不是客户承诺需求不变。
项目的参与人员在了解的需求之后，在和客户对需求的理解达成一致后，在评估了需求的技术可行性之后对客户承诺需求是可以实现的。SP1.1是本条实践的基础，是本条实践的前提。
在CMMI模型中主要在3处提到了承诺的管理，（1） REQM的SP1.2；（2）PP过程域中SP2.3:对需求进行承诺;（3）IPM过程域中SP2.2管理关键依赖的子实践，管理存在关键依赖关系的人员之间的承诺。这3处分别描述了对需求的承诺、对计划的承诺、对关键依赖关系的承诺，承诺的层次是逐步细化的，从宏观到微观，要求逐步加深。
中国人自古以来讲究一诺千金，这个“诺”是一种口头的承诺，是一种做人的信誉，在模型中提到的承诺要求一定要文档化，有记录，是书面的承诺，可以作为一种官方的依据，不能空口白说。
在实践中可以通过项目组的核心承诺对需求进行了评审、进行了估算、进行技术可行性的确认之后书面签字确认来记录。在SP1.1中要求了客户认可开发方对需求理解，客户需要书面确认，这里开发方也要进行书面承诺，二者都可能表现为书面的签字，签字的含义不同。
SP1.3 管理需求的变更
管理这个单词是在CMMI中出现频率很高的一个单词，这个单词的宾语不同含义是不同的，这里所说的管理就同这个PA的名字中的管理的含义是一致的：即保证需求的一致性。
这里所说的管理首先是要确定这个变更是应该变更的，其次要确保变更了所有相关内容，最后要确保修改的正确性，即不多改、不少改、不错改。评价是否需要变更时，需要由客户方与开发方的人员都要参与评价，不能仅仅由一方说了算，需要双方成立决策的小组，对需求的变更进行综合的评估。要考虑需求更变的技术影响、管理影响：
技术影响：
修改需求
修改设计
修改代码
修改测试用例
修改用户操作手册
产生的技术风险
……
管理影响：
变更工期
变更工作量
变更成本
变更计划
变更质量目标
……
需要建立需求变更的控制流程，是否所有的需求变更都走相同的流程呢？未必！
理解CMMI模型要灵活，不要僵化，要根据自己企业的实际情况进行裁剪。
有一家客户将需求的变更划分了高级别与低级别的两种变更，低级别的变更PM批准即可了，高级别的变更需要CCB批准：
高级别的需求变更：
影响其他项目组或者影响项目外部承诺的变更；
单次变更估算规模大于项目总体估算规模5%；
单次变更导致工作量成本增加超过1人周；
项目总体累计变更规模大于项目总体估算规模30%后的变更。
低级别的需求变更：
除上述高级别变更以外的变更。
在需求变更的流程中有几个要点需要强调：
（1） 变更的波及范围分析要完备；在进行波及范围分析时要参考需求跟踪矩阵；
（2） 需求的变更要有评审、批准；
（3） 需求变更完成后要验证变更的正确性；
（4） 变更完成后要变更基线，重新发布基线，通知相关人员。
SP1.4建立需求跟踪矩阵
需求跟踪矩阵一般简写为RTM，RTM可以表达2类跟踪关系：
横向跟踪关系：需求与需求之间的影响关系；
纵向跟踪关系：需求到设计、代码、用户文档、测试用例、计划之间的影响关系。
并非所有的跟踪关系都要建立矩阵，要根据企业的实际情况进行取舍，比如有的企业只建立客户需求到产品需求，产品需求到产品需求，产品需求到设计，产品需求到系统测试用例的跟踪关系。也并非所有的需求都要建立跟踪矩阵，比如有的企业仅对全局性的需求建立了跟踪关系。
这条实践在很多企业中都被忽略了，或者即使做了也只是形式上有了RTM，实际中并没有发现有何作用，而白白地增加了工作量。其实这条实践的作用与项目的规模很有关系，项目规模越大，这条实践的作用也越大，项目规模越小，这个实践的作用也越小。
针对RTM在我之前的博客中有多篇博文都讨论了，这里不再多说了，请搜索相关的博文看看吧。
SP1.5 识别项目计划、工作产品与需求之间的不一致性
这条实践中的字眼就是工作产品，这里说的工作产品指的设计文档、代码、用户手册、测试用例等之类的技术文档。这句话可以改写为：
识别项目计划与需求的不一致：即是否有的需求没有责任到人去开发呢？
识别设计与需求的不一致：是否有的需求没有被设计呢？是否有的设计不能满足需求呢？
识别代码与需求的不一致：是否有的需求没有被实现呢？是否有的实现不能满足需求呢？
…….
如何理解上述的识别2字呢？
识别就是找出来，识别就发现出来，识别就是评审出来，识别就是测试出来。识别的手段包括了评审、测试等验证与确认手段。这个识别不是一次性的，而是在项目进展过程持续进行多次的，这个识别是要参考RTM的。
如果发现了不一致，怎么办？记录问题，定义措施，跟踪关闭，使其保持一致！
以上对REQM的5条特定实践进行了解释，如何建立需求管理的流程呢？其实这个PA并非一定要去编写一个需求管理的流程。需要仔细分析一下，下面给出一种思路供参考：
SP1.1 可以编写到需求获取的流程中，当需求获取完成后，由客户确认需求理解的一致性；
SP1.2 可以编写到需求评审的流程中，当需求评审完成后，由开发人员确认需求的可实现性；
SP1.3 需要编写一个需求变更的流程，该流程可以合并到配置管理的变更管理流程中；
SP1.4 可以在需求开发过程中建立客户需求到产品需求，产品需求到产品需求的跟踪矩阵，可以在设计过程中建立设计到产品需求的跟踪矩阵，在测试过程中建立测试用例到产品需求的跟踪矩阵，以此类推；
SP1.5 可以在需求评审、设计评审、代码评审、测试用例评审、测试、用户手册评审、需求变更、设计变更等流程中体现识别不一致的活动。
不一定需要写一个需求管理的流程吧！
模型，要用活了！
我说CMMI之：组织过程性能
先来解释题目：何谓组织过程性能？
（1） 此PA的名字也可以翻译为组织级的过程性能，即公司级的过程性能、部门级的过程性能都可以称为组织级的过程。注意，这里讲的是组织级的过程性能，不是项目级的过程性能，所谓组织级就是跨越了多个项目组的，是多个项目的平均过程性能。项目级的过程性能的管理在QPM（量化项目管理）过程域去处理了。
（2） 何谓过程性能？过程性能是执行过程的所达到的实际结果的度量，过程的实际结果的度量包括了过程的质量、过程的效率与产品的质量。举例来讲，我们做一次项目的估算，本次估算过程的质量如何度量呢？我们可以用估算的偏差率进行度量（当然这个度量元不是很恰当，其中理由大家慢慢琢磨）；本次估算过程的效率如何呢？我们在1小时内对10页的需求文档进行了规模估算。再比如，我们做了一次需求开发的过程，我们花费了10人天的工作量完成了50页需求文档，我们过程效率为5页SRS/人天，在后续的需求评审中我们发现了需求的20个缺陷，则平均需求开发过程的质量为2个缺陷/人天，需求规格说明书的质量为0.4个缺陷/页。
（3） 过程的实际结果指的是历史数据，不是估算数据。过程性能是对过程执行情况的历史度量，以通过对历史数据的度量实现对未来的预测。
（4） 此名字中隐含了两个动词：建立与维护。即：过程域的准确名称为“建立与维护组织级的过程性能”。建立对过程性能分布的量化描述与模型，包括了过程性能的分布，包括平均值或中间值等刻画过程性能位置的度量元、上下区间等刻画过程性能离散程度的度量元以及过程性能的模型。
上述题目的含义需要细细琢磨之。
我们接下来看这个过程域的目的：组织过程性能的目的在于建立并维护对组织标准过程集的性能的定量了解，支持质量目标和过程性能目标，并且为定量管理组织的各个项目提供过程性能数据、基线和模型。
对于上述的字眼逐一解剖如下：
（1） 建立并维护=建立+使用+变更；
（2） 组织标准过程集=组织级定义的所有的标准过程；
（3） 过程（集）性能=过程的质量+过程的效率+产品的质量；
（4） 定量了解 = 收集并分析度量数据；
（5） 目标 = 对未来的期望；
（6） 质量目标=产品的质量目标；
（7） 过程性能目标=过程的质量目标+过程的效率目标；
（8） 定量管理=采用量化管理技术进行管理；
（9） 量化管理技术=统计技术+定量的非统计技术；
（10） 性能基线 = 过程性能的历史分布数据；
（11） 性能模型 = 过程的输入、属性与过程输出之间的经验公式；
于是乎，上述的过程域的目的，我们可以采用很俗的方式翻译为：OPP的目的在于采集、使用、修改对于公司级定义的所有的标准过程的度量分析数据，支持产品的质量目标、过程的质量目标和过程的效率目标，并且为采用量化管理技术管理公司的各个项目提供过程性能的度量数据、过程性能的历史分布数据以及过程的输入、属性与过程输出之间的经验公式。
请务必弄明白在这个目的中涉及到的各个名词之间的关系：
（1） 过程的输出是产品
（2） 过程有输入、输出、属性
（3） 过程的度量元包括了过程的效率元、过程质量与产品质量的度量元
（4） 过程有性能基线与性能模型
（5） 过程的管理包括了量化管理技术与非量化管理技术
（6） 过程的输出与过程的输入、属性之间可以建立模型
（7） 过程有目标
（8） 过程的目标应该受到过程性能基线、与过程性能目标的支持
这些名词都是仅仅围绕过程组织而来。CMMI是以过程为核心的，当然ISO、6sigma等管理模型也是如此。
这个PA的特定目标只有一个：建立并维护刻画组织标准过程集的期望的过程性能的基线和模型。前面我们讲透了目的的含义了，这个目标的含义自然就明白了，所以我们直接进入对特定实践的解释。这个PA特定实践有5条：
SP 1.1 选择过程
SP 1.2 建立过程性能度量元
SP 1.3 建立质量目标和过程性能目标
SP 1.4 建立过程性能基线
SP 1.5 建立过程性能模型
以下逐条解释之。
SP1.1 选择过程
实践原文：Select the processes or subprocesses in the organization's set of standard processes that are to be included in the organization's process-performance analyses.
参考译文：从组织标准过程集中选择将要包含在组织过程性能分析中的过程或子过程。
还是先解释这个实践中出现的名词。首先看组织过程性能分析，何意？组织过程性能分析即分析组织过程性能的分布、能力、模型等，分布即统计分布的类型、数据的位置、数据的离散程度，能力即与目标的偏离，模型及输出与输入、过程属性之间的量化关系。假如我们曾经做了20次系统测试，统计了：
Ø 每次系统测试投入的工作量；
Ø 设计的测试用例的个数；
Ø 测试的工期；
Ø 找到的缺陷个数；
Ø 被测代码的行数；
则我们可以得到：
Ø 每次测试的缺陷检出密度（缺陷个数/代码行数）；
Ø 缺陷检出效率（缺陷个数/测试工作量）；
Ø 测试速率（代码行数/测试工期）。
对于上述的缺陷检出密度，我们可以计算出这20次测试的平均值及其浮动的范围，这便是分布。浮动范围的确定有多种方法，我们后边再讲，总之，是有办法确定其分布范围的。如果我们组织级确定了量化的质量目标，要求我们每次做系统测试的缺陷密度都必须在某一个浮动范围内，则分析实际范围与目标范围的偏离或重合程度即为过程能力的分析。我们建立测试的工作量、测试用例个数、测试工期、被测代码的行数与缺陷检出密度之间的量化关系则为性能模型。上述的这3个动作即是做过程性能分析。即：
过程性能分析=建立过程性能分布+建立过程性能模型+过程性能能力分析。
过程性能的分布即为过程性能基线（baseline）,此处的基线，也可以翻译为基准、标杆，不要和配置管理中的基线概念混淆了，这里是性能基线不是配置基线。
SP1.2 选度量元
度量元的表达能力
SP1.3 定目标
目标是个区间不是单点值
SP1.4 建立性能基线
在实践中最常用的建立基线的方法有两种：
箱线图法与控制图法。
方法，分别举例说明之
我说CMMI之：风险管理过程域
风险与问题的区分。
地震发生了，可能造成瘟疫，瘟疫可能失控，导致人员死亡。
严重性，可能性，紧迫性
我说CMMI之：需求开发
需要的必要和充分的含义
我说CMMI之：项目策划过程域
要不要PMO:批准项目，外部协调，重大风险
何谓资料管理？
我说CMMI之：项目监督与控制过程域
偏差率的确定是在哪里确定的？
计划了什么就跟踪什么
跟踪要做数字的比较
跟踪的方式有多种：
会议跟踪：
每日例会
每周例会
每月例会
每阶段例会
个别跟踪：
个人日志
单独跟踪
高层的参与
风险的监督与风险管理的关系
该PA与其他PA的关系：在项目进展过程中，还需要修改计划。
人员参与的监督？监督什么？
里程碑评审的目的，方法
里程碑关闭的标准
识别问题？管理问题？
我说CMMI之：软件度量
度量目标
我说CMMI之：配置管理
配置项与资料项之间的关系
配置项的概念
基线的概念
基线，受控，开发
CCB的构成
我说CMMI 集成项目管理
解释题目：集成的含义，集成的翻译方法
我说CMMI 决策与解决方案
专家打分
我说CMMI之七：如何实施CMMI
如何实施CMMI这个题目很大。实施的流程
IDEAL
PDCA
如何灵活
精简概念与活动，用语通俗
减少PM的精神压力
精神负担
我说CMMI之：过程有关的基本概念
我们做过程管理，天天都在讲过程二字，真要给过程下个定义却没有那么容易。正如我们天天说某某是好人，某某是坏人，啥是好人，啥是坏人很难明确定义。但是这却是无法回避的问题，因此我们必须给过程下一个定义。
在CMMI模型中对过程下了一个定义，全文如下：
In the CMMI Product Suite, activities that can be recognized as implementations of practices in a CMMI model. These activities can be mapped to one or more practices in CMMI process areas to allow a model to be useful for process improvement and process appraisal. (See also “process area,” “subprocess,” and “process element.”)
There is a special use of the phrase “the process” in the statements and descriptions of the generic goals and generic practices. “The process,” as used in Part Two, is the process or processes that implement the process area.
与其说是下了一个定义，其实和啥都没说一样。
ISO 9000-2008 :
将输入转化为输出的相互关联或相互作用的一组活动。
子过程是CMMI4级中很重要的一个概念，在CMMI2、3级中没有提到此概念。这个概念往往是很多做高成熟度改进的企业所忽略或不能理解的。在去理解这个概念又涉及到了其他的多个概念，在CMMI中对子过程的定义为：
A process that is part of a larger process. A subprocess can be decomposed into subprocesses and/or process elements.
在此定义中又涉及到了过程元素的概念，我们再找出来过程元素的概念看看：
The fundamental unit of a process. A process can be defined in terms of subprocesses or process elements. A subprocess can be further decomposed into subprocesses or process elements; a process element cannot.
Each process element covers a closely related set of activities (e.g., estimating element and peer review element). Process elements can be portrayed using templates to be completed, abstractions to be refined, or descriptions to be modified or used. A process element can be an activity or task.
The terms “process,” “subprocess” and “process element” form a hierarchy with “process” as the highest, most general term, “subprocesses” below it, and “process element” as the most specific.
上述2个定义结合起来，我们可以这么理解：大过程由小过程构成，小过程即子过程，子过程又可以分解为子过程或过程元素，过程元素是最小的子过程，不能再拆分为子过程了，子过程由活动构成，过程元素由一系列紧密相关的活动构成，过程元素也可以一个活动或任务。
这里面还要仔细去理解大过程由小过程构成的含义。所谓的构成可以有2种含义：
（1） 整体部分关系；
（2） 继承关系。
比如我们讲评审过程，评审过程又包括了三种方法：审查、技术复审、走查，这3种方法都定义了各自的流程，那么评审过程与这3种评审过程之间是什么关系呢？这就是一种继承关系。审查过程划分为了5个大的活动集：准备、概况会议、个人评审、记录会议、返工处理，则每个大的活动集可以视为是一个过程元素。
结合二三级里提到的生命周期、阶段、过程、过程架构的概念，我们可以用下面的类图表达这些概念之间的关系：
我说CMMI 之：共性实践
CMMI的等级有两种划分：组织成熟度等级和过程域能力等级。前者是从“面”上对组织进行整体的提升，后者则是从“点”上针对一个或几个过程域重点突破。
组织成熟度各个等级包含了固定的过程域集合，以评价组织的整体状况；过程域能力各个等级则代表了与该过程域相关过程的执行能力。两者之间有着紧密的联系，例如，达到了组织成熟度2级，代表2级包含的7个过程域至少达到了能力成熟度2级；同时，也可以自选几个过程域，将其能力等级提升到3级或更高,但如果没有覆盖3级包含的18个过程域，则其组织成熟度等级仍然是2级。
过程改进时，也可以重点选几个过程域进行能力提升，再循序渐进，积累到足够的量时，整个组织的成熟度等级提升也就水到渠成了。
如何达成不同的过程域能力等级？通过共性目标和共性实践来达成。
| 共性目标 | 对应的能力等级 | |
| GG 1 | 达成特定目标 | 已执行的过程 |
| GG 2 | 制度化已管理的过程 | 已管理的过程 |
| GG 3 | 制度化已定义的过程 | 已定义的过程 |
| GG 4 | 制度化已定量管理的过程 | 已定量管理的过程 |
| GG 5 | 制度化不断优化的过程 | 不断优化的过程 |
“制度化”的含义是过程的执行已经形成了组织的一种制度、规章乃至根深蒂固的文化，不会迫于压力或其他事由而放弃或者缩水。
对于所有过程域，共性目标是完全相同的，这也是“共性”这个词的由来。每个共性目标下又有其对应的共性实践来达成目标。
GG 1达成特定目标
Ø GP 1.1 执行特定实践
过程域中所有特定实践都被执行，是达到其它等级的基础。
GG 2制度化已管理的过程
Ø GP 2.1 建立组织方针
Ø GP 2.2 策划过程
Ø GP 2.3 提供资源
Ø GP 2.4 分配职责
Ø GP 2.5 培训人员
Ø GP 2.6 管理配置
Ø GP 2.7 识别并引入利益相关者
Ø GP 2.8 监控过程
Ø GP 2.9 客观评价过程
Ø GP 2.10 高层管理者评审状态
目标2有多达10条共性实践，可概括为在执行了特定实践的基础上，还要保证其“有方针”“有策划”“有监控”，即“三有”。
Ø GP 2.1
方针是组织对过程执行定义的指导原则和要求，如“所有项目都要有项目初估和细估”。方针一般要求简明易记，琅琅上口，比如运动会常提的“友谊第一，比赛第二”。
Ø GP 2.2到GP2.7
策划是任务和进度安排、资源的提供、职责的分配、人员的培训等等需要事先明确的事项。
Ø GP 2.8到GP2.10
监控是执行者内部的监控、PPQA的审计、高层经理的参与。
综上，所谓已管理的过程即“有方针”“有策划”“有监控”的过程。
GG 3制度化已定义的过程
Ø GP 3.1 建立以定义过程
在达成目标2的基础上，基于组织的标准过程裁剪适合于自身的已定义过程。
例如，组织对项目策划活动有标准的规定，分估算、建立计划、计划评审三步走，但每个项目组在实际进行策划时，应该基于项目的特点和需求调整之，如选择合适的估算时机和方法、增/删必要和不必要的计划书细节、明确计划评审的细节等，这类调整，统称裁剪。
Ø GP 3.2 收集改进信息
过程执行中还需要收集各类产物、建议、数据、经验和教训等，使组织的标准过程和资产不断完善和丰富。
综上，标准过程保证了过程的规范和共性，裁剪体现了规范和灵活的平衡，而收集改进信息则是过程不断提升的来源。
GG 4 制度化已定量管理的过程
Ø GP 4.1 建立过程的定量目标
Ø GP 4.2 稳定子过程性能
GG 5制度化不断优化的过程
Ø GP 5.1 确保持续改进
Ø GP 5.2 纠正问题的根本原因
目标4和目标5加起来只有4条共性实践，但达成的话有相当的难度，因为这4条实践等效于成熟度等级4级和5级的4个过程域的特定实践。
目标4及其共性实践是根据组织的商业目标、发展战略等，选择对其有重要影响的过程或子过程，使用统计学的手段去分析并控制，使其稳定、可控、可预测。
目标5及其共性实践则是使用“刨根问底”的方法对组织中共通的问题进行原因挖掘，采取合理的措施乃至变革，既要治本，必要时又得不破不立，从根本上去提升组织的过程。
更多的4级和5级的内容，请学习博客的高成熟度等级的相关文章。
![门户通专访草根站长九天狼：做站贵在坚持[图]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)