cmmi整体框架和重点过程域解释

模型规范级别及其过程域成熟度1级：初始级①软件过程的特点是无序的，偶尔甚至是混乱的。

几乎没有什么过程是经过定义的，成功依赖于个人的努力；②一般不提供开发和维护软件的稳定环境,在危机时刻,项目一般抛弃预定的规程,回复到仅做编码和测试，性能依赖于个人的能力，且随个人固有的技能、知识和动机的不同而变化。

成熟度2级：受管理级①在成熟度等级2上，意味着组织要确保策划、文档化、执行、监督和控制项目级的过程；②为过程建立明确的目标，并能实现所确定的诸如成本、进度和质量目标等目标。

③换言之，组织已经营造出稳定的、受控的开发环境，项目是在受控状态下运行。

受管理级过程域•需求管理(REQM)•项目策划(PP)•项目监督与控制(PMC)•供方协定管理(SAM)•测量和分析(MA)•过程和产品质量保证(PPQA)•配置管理(CM)成熟度3级：已定义级在成熟度等级3上，项目执行过程是通过剪裁组织的标准过程集合和组织过程财富产生的“已定义过程”，并具备与该过程相适应的运行环境。

其与成熟度等级2的区别在于标准、过程描述、规程的应用范围是全组织级的。

•需求开发(RD)•技术解决(TS)•产品集成(PI)•验证(VER)•确认(V AL)•组织过程聚焦(OPF)•组织过程定义(OPD)•组织培训(OT)•集成项目管理(IPM)•风险管理(RSKM)•决策分析和决定(DAR)成熟度4级：定量管理级在成熟度等级4上，组织建立了关于产品质量、服务质量及过程性能的定量目标，运用统计技术和其他定量目标作为判断过程管理成功与否的标准。

在过程的整个生存周期里，对产品质量、服务质量和过程性能做到统计意义上的了解和管理。

•组织过程性能(OPP)•定量项目管理(QCM)成熟度5级：持续改进级成熟度等级5 的突出特征是过程性能的持续改进。

组织建立起整个组织的定量过程改进目标，并且把它们作为过程改进管理成功与否的判断标准；这些目标将适时修改，以反映不断变化的本组织的业务目标。

CMMI级过程域讲解CMMI（Capability Maturity Model Integration）是一种用于评估和改进软件开发过程的框架。

它通过对软件开发组织的过程进行评估，为组织提供了一个逐步改进过程的路径，从而提高组织的能力和成熟度。

CMMI框架包括五个过程域，它们是：项目管理、项目支持、要素工程、项目环境和组织过程。

每个过程域都有一组特定的目标和实践，用于评估和改进相关的软件开发过程。

首先是项目管理过程域，它关注的是项目的计划、执行和监控。

它包括了项目管理的三个关键方面：计划制定、项目监控和项目管理。

项目管理过程域的目标包括项目计划的制定、项目资源的分配和控制、项目风险的管理和项目进展的监控。

其次是项目支持过程域，它提供了支持项目管理过程的各种资源和服务。

项目支持过程域包括配置管理、度量和分析、决策分析和解决方案评价等方面。

其目标包括配置管理的实施、度量和分析的开展、决策分析和解决方案评价的应用。

第三个是要素工程过程域，它关注的是软件开发中所使用的各种工具和技术。

要素工程过程域包括需求开发、技术解决方案、产品集成和验证、产品交付等方面。

其目标包括需求开发的实施、技术解决方案的应用、产品集成和验证的实施、产品交付的管理。

第四个是项目环境过程域，它关注的是项目所处的环境因素对项目成功的影响。

项目环境过程域包括了风险管理、分析过程和产品市场分析等方面。

其目标包括风险管理的实施、分析过程的开展、产品市场分析的应用。

最后是组织过程过程域，它关注的是软件开发组织的过程管理。

组织过程过程域包括组织过程的定义、组织过程管理的实施和过程改进等方面。

其目标包括组织过程的定义和实施、组织过程管理的应用、过程改进的管理。

总而言之，CMMI级过程域是一个用于评估和改进软件开发过程的框架。

它包括了五个过程域，分别是项目管理、项目支持、要素工程、项目环境和组织过程。

每个过程域都包含了一系列的目标和实践，用于评估和改进相关的软件开发过程。

CMMI过程域CMMI（Capability Maturity Model Integration）是一种用于评估和改进组织的软件工程能力的模型。

它定义了一组评估标准和最佳实践，包括了五个过程域（process area），分别是需求管理、项目管理、工程（软件）过程、配置管理和产品质量保证。

接下来，我将详细介绍这五个过程域。

1. 需求管理（Requirements Management）需求管理是指在整个软件开发过程中，对需求的分析、收集、跟踪和变更进行管理。

主要活动包括需求识别、需求分析和建模、需求验证和确认以及需求变更管理。

需求管理的目标是明确项目的需求，确保需求的准确性和可追溯性，以及及时有效地处理需求变更。

通过有效的需求管理，可以实现项目的高效开发和产品的质量保证。

2. 项目管理（Project Management）项目管理是指对软件开发项目进行计划、组织、指导和控制，以实现项目目标的过程。

主要活动包括项目计划制定、资源分配和调度、进度控制和风险管理。

项目管理的目标是确保项目按时、按质量要求完成，最大程度地满足客户需求。

通过有效的项目管理，可以提高项目的可预测性和控制性，减少项目风险，并提高项目团队的合作效率。

3. 工程（软件）过程（Engineering Process）工程过程是指在软件开发过程中，进行软件需求分析、设计、编码、测试和维护的一系列工作。

主要活动包括软件需求分析、软件构架设计、编码和单元测试、集成测试和系统测试以及软件维护。

工程过程的目标是确保软件开发过程高效、规范和可靠，以达到预期的质量和性能要求。

通过有效的工程过程，可以提高软件开发效率，减少错误和缺陷，提高软件的可维护性和可靠性。

4. 配置管理（Configuration Management）配置管理是指对软件产品配置项进行识别、控制、记录和审计的过程。

主要活动包括配置项识别和建立配置管理库、配置项控制和跟踪变更、配置项版本管理和配置项审核。

CMMI基本概念要点CMMI（Capability Maturity Model Integration）能力成熟度模型集成，是一种在组织和团队中度量和改进软件和系统工程能力的国际标准模型。

CMMI基于过去对软件工程和系统工程最佳实践的研究和经验，通过一系列的阶段和培训，帮助组织提高其过程的成熟度和质量，以便更好地满足客户需求和提供价值。

以下是CMMI的一些基本概念要点：1. 成熟度级别（Maturity Levels）：CMMI定义了五个成熟度级别，分别是初始级、可重复级、已定义级、已管理级和已优化级。

每个级别都有特定的目标和过程特点，组织可以按照这些级别逐步改进其软件工程和系统工程能力。

2. 能力级别（Capability Levels）：CMMI还定义了六个能力级别，分别是未实施级、已执行级、已定义级、已管理级、已预测级和已优化级。

能力级别是针对特定过程或实践的细分评估，组织可以用它来评估和度量其各个过程的成熟度。

3. 关键过程领域（Key Process Areas）：CMMI将软件工程和系统工程划分为22个关键过程领域。

每个关键过程领域都描述了组织达到特定目标所需的一组过程。

这些过程领域包括需求管理、配置管理、项目计划等，可以通过培训和改进来提高组织的能力。

4. 成熟度级别的目标和实践（Goals and Practices）：CMMI对于每个成熟度级别都定义了一组目标和相关实践。

这些目标描述了组织在特定成熟度级别中应该达到的状态，而实践则提供了实现这些目标的具体方法。

5. 过程改进（Process Improvement）：CMMI强调了持续的过程改进的重要性。

组织通过采纳CMMI指南中的最佳实践和建议，可以改进其软件工程和系统工程过程，提高效率、质量和客户满意度。

6. CMMI的评估和认证（Assessment and Certification）：组织可以通过CMMI评估来测量其软件工程和系统工程能力的成熟度水平。

CMMI3级18个过程域CMMI（Capability Maturity Model Integration）是一种用于评价和改进组织的软件工程能力的模型。

CMMI模型将软件工程能力分为不同的级别，目前最高级别是CMMI级别5、在CMMI模型中，共有18个过程域，每个过程域都包含一组过程目标和过程实践。

下面将介绍CMMI级别3中的18个过程域，并对每个过程域进行详细解析。

1. 要求开发（Requirements Development）：该过程域涉及确定、分析和记录系统和软件需求的活动。

它包括需求的获取、管理、分析和验证。

2. 要求管理（Requirements Management）：该过程域涉及组织和控制项目的需求。

它包括需求的识别、跟踪、控制和变更管理。

3. 项目计划和监控（Project Planning and Monitoring）：该过程域涉及制定和维护项目计划，并监控项目活动的执行。

它包括识别和规划项目活动、建立项目计划、监控项目进展和基于此进行调整。

4. 项目监控和控制（Project Monitoring and Control）：该过程域涉及监控和控制项目执行过程中的工作和活动。

它包括收集和分析项目绩效数据、对比实际和计划绩效，对项目进展进行控制。

5. 供应商协议管理（Supplier Agreement Management）：该过程域涉及与供应商达成协议，并管理和监控供应商的活动。

它包括选择供应商、与供应商协商、管理和控制供应商的交付和绩效。

6. 产品集成（Product Integration）：该过程域涉及对各个组成部分进行整合，形成最终产品。

它包括定义和实施产品集成策略、执行产品集成和验证集成后的产品。

7. 风险管理（Risk Management）：该过程域涉及识别、评估和控制项目和产品的风险。

它包括制定风险管理计划、识别和评估风险、并采取相应的风险缓解措施。

8. 决策分析和解决方案评估（Decision Analysis and Resolution）：该过程域涉及通过分析和评估不同的解决方案，制定决策。

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的22个过程域及其特定目标和实践CMMI共含有22个过程域：一、项目管理类：1、项目策划（PP）：SG1 完成参数估计SP1.1 估计项目的范围SP1.2估计项目属性SP1.3确定项目生存周期SP1.4 确定工作量和成本的估计值SG2 拟订项目计划SP2.1 编制预算和进度 SP2.2识别项目风险 SP2.3策划数据管理 SP2.4策划项目资源 SP2.5 策划必要的知识和技能 SP2.6策划共利益者的介入 SP2.7拟订项目计划SG3 获得对计划的承诺SP3.1 审查从属计划 SP3.2使工作与资源配备协调 SP3.3获得计划承诺2、项目监督和控制（PMC）：SG1 对照计划监督项目SP1.1 监督项目策划参数 SP1.2 监督承诺 SP1.3监督项目风险 SP1.4监督资料管理 SP1.5监督共利益者介入情况 SP1.6进行进展审查 SP1.7里程碑审查SG2 管理纠正措施，直到结束SP2.1 分析问题：收集并分析问题，确定处理这些问题所需的纠正措施SP2.2 采取纠正措施：对所识别的问题采取纠正措施3、集成项目管理（IPM）+IPPDSG1运用项目已定义过程SP1.1建立项目已定义过程 SP1.1运用组织过程财务策划项目活动 SP1.1建立项目工作环境综合计划 SP1.1运用综合计划管理项目 SP1.1充实组织过程财富SG2与相关的共利益者协调和合作SP2.1管理共利益者介入 SP2.2管理依存关系 SP2.3解决协调问题SG3IPPD应用（应用IPPD原则）SP3.1 建立项目的共同愿景 SP3.2 建立集成团队架构 SP3.3 分配需求至集成团队 SP3.4 建立集成团队 SP3.5确保跨团队间的合作4、供方协定管理（SAM）SG1 建立供方协定SP1.1分析由项目所决定的需求 SP1.2选择供方 SP1.3 建立供方协定SG2 满足供方协定SP2.1执行供方协定 SP2.2监督选定的供方过程 SP2.3评估选定的供方工作产品 SP2.4接受取得的产品 SP2.5移交产品5、风险管理（RSKM）SG1 准备风险管理SP1.1确定风险来源和类别 SP1.2定义风险参数 SP1.3建立风险管理战略SG2 识别和分析风险SP2.1识别风险 SP2.2对风险进行评价、分类和排列优先顺序SG3 缓解风险SP3.1拟订风险缓解方案 SP3.2实施风险缓解6、定量项目管理(QPM)SG1定量管理项目SP1.1建立项目目标 SP1.2组成已定义过程 SP1.3选择将予以管理的子过程 SP1.4管理项目性能SG2对子过程进行统计管理SP2.1选择度量值和分析技术 SP2.2运用统计方法，以掌握变化情况 SP2.3监督所选择的子过程的性能 SP2.4记录统计管理数据二、工程类1、需求管理（RM）2、需求开发（RD）3、技术解决（TS）SG1 选择产品构建解决方案SP1.1开发详细候选解决方案和选择准则 SP1.2开发操作概念和场景 SP1.3选择产品构件解决方案SG2 设计SP2.1运用有效的设计方法 SP2.2建立完备的技术数据包 SP2.3设计综合性接口 SP2.4进行制作、购买或复用分析SG3 实现产品设计SP3.1实现设计 SP3.2编制产品支持文档4、产品集成（PI）SG1 准备产品集成SP1.1建立产品集成战略 SP1.2建立产品集成环境 SP1.3规定详细的产品集成规程SG2 确保接口兼容性SP2.1审查接口描述的完备性 SP2.2管理接口SG3 组装产品构件和交付产品SP3.1确认集成用的产品构件已经准备就绪 SP3.2组装产品构件 SP3.3核查组装的产品构件 SP3.4打包和交付产品或产品构件5、验证（VER）6、确认（VAL）三、组织过程类：1、组织过程定义（OPD）SG1 建立组织过程资产SP1.1建立标准过程 SP1.2 建立生命周期模型描述 SP1.3建立裁剪准则及指南 SP1.4建立组织度量库 SP1.5建立组织过程资产库 SP1.6建立工作环境标准SG2 促成IPPD管理SP2.1建立授权机制 SP2.2建立集成团队规则与指南 SP2.3平衡团队与原隶属组织的责任2、组织过程聚焦（OPF）SG1 确定过程改进机会SP1.1确定组织的过程需求 SP1.2评估组织的过程 SP1.3识别组织的过程改进项目SG2 策划和实施过程改进活动SP2.1制定过程行动计划 SP2.2实施过程行动计划 SP2.3部署过程和相关的过程财富 SP2.4把过程相关的经验纳入本组织的过程财富3、组织培训（OT）SG1 确定培训需求并且使培训现成可用SP1.1 确定战略培训需求 SP1.2确定有哪些培训需求由组织负责满足 SP1.3 建立组织培训战术计划 SP1.4建立培训能力SG2 提供必要的培训SP2.1交付培训 SP2.2建立培训记录 SP2.3评价培训效果4、组织过程性能（OPP）SG1 建立性能基线和模型SP1.1 选择过程 SP1.2建立过程性能度量值 SP1.3建立质量和过程性能目标 SP1.4建立过程性能基线 SP1.5建立过程性能模型5、组织革新与部署（OID）SG1 选择改进项目SP1.1 收集和分析改进建议 SP1.2 识别革新 SP1.3 试行改进 SP1.4 选择改进建议，用于部署SG2 部署改进SP2.1策划部署 SP2.2管理部署 SP2.3度量改进效果四、支持类1、过程和产品质量保证（PPQA）SG1 客观评价过程和工作产品SP1.1客观评价过程 SP1.2客观评价工作产品和服务SG2 客观提供情况SP2.1通报不符合问题，并且确保解决它们 SP2.2建立记录2、配置管理（CM）SG1 建立基线SP1.1识别配置项 SP1.2建立配置管理系统 SP1.3建立或放行基线SG2 跟踪并控制变更SP2.1跟踪变更 SP2.2控制变更SG3 建立完整性SP3.1建立配置管理记录 SP3.2进行配置审计3、测量和分析（MA）SG1 协调测量和分析活动SP1.1 建立测量目标 SP1.2详细说明度量值 SP1.3说明数据收集和存储规程 SP1.4规定分析规程SG2 提供度量结果SP2.1收集度量数据 SP2.2分析度量数据 SP2.3存储数据和结果 SP2.4通报分析结果4、决策分析和决定（DAR）SG1 评价候选方案SP1.1拟订并运用决策分析的指导原则 SP1.2选择评价技术 SP1.3拟订评价准则 SP1.4确定推荐的侯选方案 SP1.5评价候选方案 SP1.6选择解决方案5、原因分析和决定（CAR）SG1 确定缺陷的原因SP1.1选择缺陷数据，用于分析、选择缺陷和其他问题，以供分析使用 SP1.2分析原因SG2 处理缺陷原因SP2.1实施措施建议 SP2.2评价变更的效果 SP2.3记录数据。

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的PA（过程域）概述CMMI普及知识——第⼆期CMMI的PA（过程域）概述关键词：PA——过程域CMMI的阶段式表⽰法——组织成熟度⽅法我们采⽤阶段式模型来描述。

阶段式模型使⽤ML1~ML5五个级别的表现形式ML(maturity level)。

整个CMMI模型中的25个PA 分别分布在ML2~ML5中，如果全部做到了哪个等级以下的PA，那么就可以说我们达到了⼏级。

ML1——初始级：没有PAML2——已管理级：包括7个PAREQM-需求管理PP-项⽬策划PMC-项⽬监控和控制CM-配置管理PPQA-过程和产品质量保证SAM-供应商协议管理MA-度量和分析ML3——已定义级：包括14个PARD-需求开发TS-技术解决⽅案PI-产品集成VER-验证VAL-确认IPM-集成项⽬管理RSKM-风险管理OPF-组织级过程焦点OPD-组织级过程定义OT-组织级培训DAR-决策分析与决定IT-集成团队ISM-集成供应商管理OEI-组织集成环境ML4——定量管理级：包括2个PAQPM-定量项⽬管理OPP-组织级过程性能ML5——优化级：包括2个PAOID-组织⾰新和实施CAR-因果分析和决定华迪公司的⽬标：通过18个⽉的过程改进⼯作，使组织的能⼒成熟度达到ML3，即全部做到ML2~ML3的所有PA。

BTW：以后的专题将⼀⼀详细介绍ML2~ML3中每个PA的内容，同时欢迎公司内部所有对过程改进感兴趣的同仁发表你宝贵的观点、意见和建议，让我们的过程改进⼯作更加务实、有效，能真正为实训、信息化、外包等业务服务。

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软件过程体系结构CMMI（Capability Maturity Model Integration，能力成熟度模型集成）是美国软件工程协会（SEI）在软件工程领域的一种通用的质量管理模型，也是目前国际上最成熟的软件过程成熟度评价模型之一、CMMI 为软件开发组织提供了一种有效的方式来评估自身的软件过程能力，并通过逐步提高和成熟的过程能力来保证软件项目的成功。

CMMI的核心要素是软件过程体系结构。

软件过程体系结构是一个包括过程域、过程目标、关键实践和指导的框架，用于指导软件组织开展连续改进和提高过程能力。

在CMMI中，过程域是一个集合，包含了与软件工程相关的一组过程。

过程目标是定义每个过程域中需要实现的结果。

关键实践则是指导组织如何实现过程目标的一组活动。

指导则是提供了执行关键实践的细节方法，包括实施所需的资源和工具。

CMMI软件过程体系结构包括5个级别，分别是初始级、管理级、定义级、量化管理级和优化级。

每个级别都定义了一组与过程成熟度相关的过程目标和关键实践。

不同的级别代表了组织对软件过程成熟度的不同要求和目标。

初始级是最低级别，表示组织尚未建立有效的软件过程管理能力。

在初始级别中，组织的软件过程通常是不可靠和无法预测的。

管理级是一个基本的过程管理级别，要求组织建立基本的过程管理能力，并能够规划和管理软件项目的资源、进度和风险。

定义级则要求组织在管理级基础上进一步定义和文档化软件过程。

量化管理级要求组织能够度量和控制软件过程，以便实现可持续的过程改进和性能管理。

优化级是最高级别，要求组织能够以持续改进和创新的方式管理和优化软件过程。

CMMI软件过程体系结构的优势在于它提供了一种清晰和系统的方法来评估和改进软件过程能力。

通过实施CMMI，软件组织可以提高软件开发的质量和可靠性，减少开发风险，提高项目交付的可预测性和可控性。

此外，CMMI还可以帮助软件组织实现员工的技能提升和职业发展，提高组织的竞争力和市场地位。

CMMI Level 2 GP2.1 方针GP2.1 方针对每一个PA，公司都应该有相应的高层次的要求来指导该方面的工作，也就是所谓的方针。

方针这东西很很容易被认为是虚的东西，我们需要仔细体会方针，这个GP是公司商业目标与过程的结合点，过程是否能为商业目标带来价值，很大程度上就看这个方针是怎样定的，并且要把方针贯彻到过程中。

我们以PP这个PA为例子，如果微软要定PP的方针，我想会是：1.赋予小组成员权力，每个人都承担项目管理的责任；2.保持灵巧，预测变化；3.由底而上的估算办法；......在MSF中，我们会看到很多微软进行项目管理的一些原理和法则，这些法则，指导着如何做项目计划，不同的这些方针指导下，做出来的过程是不一样的。

每个公司都有自己的特点、商业目标、企业文化等，最开始我们可能难以制定出详细具体的过程，但首先要把这些过程的指导原则想好，方针是过程的灵魂，过程是否有魅力，是否可以让大家“愉快地”执行，关键就是看过程的方针了。

在我们公司，所有过程都遵循这样的一个方针，就是简单有效，我们要求所有过程都是必须用来执行的，做不到的过程不做，没有效果的过程不要，因为有这样一个原则，我们需要发动所有执行过程的同事来参与制定过程，以保证“简单有效”。

我们除了有简单有效这样的一个大原则，每个PA又会制定自己相应的方针。

大家在制定方针内容的时候，要从高层及执行过程的员工两个层面同时下手，整理出简单的有效的容易记忆的方针，并且在以后不断更新这个方针，保证这个方针能不断促进公司的发展。

项目监督和控制计划不是用来看的，是用来执行的。

PP讲述了如何做计划，PMC讲述的就是如何跟踪计划的执行并在实际情况偏离计划时采取纠正行动。

我们先看看SG1，SG1讲述的是如何根据计划来跟踪计划的执行问题。

SG1: Actual performance and progress of the project are monitored against the project plan.中文大意是：根据计划，跟踪项目的实际性能和过程。

CMM关键过程域CMM（Capability Maturity Model）是一个软件工程目标模型，用于评估和改进组织的软件开发过程的能力。

它将软件开发过程分为五个层次，从初始（Level 1）到最优化（Level 5），每个层次都代表着一定的过程成熟度。

CMM的五个层次称为“关键过程域”，每个关键过程域都代表了一个关键的软件开发活动。

1.软件需求管理软件需求管理是指通过适当的技术和工具，对软件需求进行识别、分析、规划和管理的过程。

在这个关键过程域中，组织应明确定义需求，制定合适的需求开发计划，并确保需求管理过程与其他项目管理过程有效地整合。

2.软件项目计划与管理软件项目计划与管理是指通过合适的技术和工具，对软件开发项目的范围、任务、资源、进度和风险进行计划和管理的过程。

在这个关键过程域中，组织应制定一个合适的项目计划，明确项目的目标、范围和约束条件，并建立一个有效的项目管理过程来确保项目按时、按质量地完成。

3.软件工程与迭代开发软件工程与迭代开发是指通过适当的技术和工具，设计、开发和验证高质量的软件的过程。

在这个关键过程域中，组织应建立一个适当的软件开发方法，确保软件开发过程的可控性和迭代性，并建立一个有效的软件工程过程来确保软件的质量。

4.软件产品集成与测试软件产品集成与测试是指通过适当的技术和工具，将各个软件组件整合在一起，并进行验证和确认的过程。

在这个关键过程域中，组织应确保软件组件集成的有效性和可靠性，并建立一个有效的软件测试过程来确保软件在各个集成阶段的质量。

5.软件配置管理软件配置管理是指通过适当的技术和工具，对软件产品的配置项进行控制和管理的过程。

在这个关键过程域中，组织应建立一个适当的配置管理策略，确保软件配置项的完整性和一致性，并建立一个有效的配置管理过程来确保软件配置的可追溯性和可控性。

这些关键过程域是CMM模型的基础，组织可以通过评估它们的成熟度来确定自己的软件开发能力，并制定相应的改进措施。

CMMI3级过程域介绍CMMI（Capability Maturity Model Integration）是一种被广泛应用于组织软件过程改进的方法。

CMMI将组织的软件开发过程分为多个过程域，它们对一个成熟的软件开发实践进行了定义和标准化。

CMMI 3级是CMMI的一种成熟级别，它把软件开发过程纳入了一个良好安排和控制的过程中，以帮助组织实现可持续的软件开发和交付质量。

本文将介绍CMMI 3级过程域的一些主要内容。

软件项目管理过程域（Project Management）软件项目管理过程域关注的是软件开发项目的规划、组织、协调和控制方面的活动。

在该过程域中，组织需要制定一个合理的软件项目计划，确保项目的范围、进度和成本得以有效控制。

此外，还要建立有效的风险管理和配置管理机制，以便提早发现和解决问题。

配置管理过程域（Configuration Management）配置管理过程域主要关注的是软件产品的版本和配置控制。

在该过程域中，组织需要制定适当的配置管理策略和规程，确保软件产品的每个版本都能得到正确的记录和控制。

此外，还需要建立一个有效的变更管理机制，以便评审、审批和实施软件产品的变更。

要求管理过程域（Requirements Management）要求管理过程域关注的是软件开发项目的需求制定、分析和管理。

在该过程域中，组织需要确保软件开发项目的需求得到有效的收集、分析和记录，以便为后续的开发活动提供指导和基础。

此外，还要确保需求的正确性、可追溯性和一致性，以减少后期的需求变更和重复工作。

项目监控和控制过程域（Project Monitoring and Control）项目监控和控制过程域关注的是软件开发项目的监控和控制活动。

在该过程域中，组织需要建立有效的项目监控机制，跟踪项目的进展、成本和风险，并及时采取措施来纠正偏差。

此外，还要确保与项目相关的信息得到及时和正确地传达，以保证项目的顺利运行。