需求开发与需求管理指引
CMM中的需求管理与需求开发
需求管理（Requirements Management ）是属于CMM2中的过程域，简称为REQM ，需求开发（Requirements Development ）是CMM3中的过程域，简称RD 。
这两个过程域是CMMI 体系中关于需求的全部内容，下面分别对这两部分进行介绍。
本文对CMM 的一些基础知识、基础术语不再介绍。
需求管理与需求开发的分界线：市场营销用户需求管理层需求开发需求管理市场营销管理层项目环境项目变更 大家可以这样理解，需求管理是指对需求变更的管理、对需求的跟踪，而获取需求、定义需求则属于需求开发部分。
需求管理在CMMI 中，需求管理的目标定义为：a. 把软件需求建立一个基线供软件工程和管理使用。
b. 软件计划、活动和工作产品同软件需求保持一致。
更高的目标：软件需求的复用需求管理的原则和方法a. 必须与需求工程的其他活动紧密整合b. 需求必须是文档化的、正确的、最新的、可管理的、可理解的c. 只要需求变化了，需求变更的影响就必须被评估d. 需求必须分优先级e. 需求一定要分类管理需求管理的主要工作：特定目标和特定实践特定目标●管理需求管理需求并识别需求与项目计划和工作产品之间的差异。
●SP 1.1 取得需求理解●SP 1.2 取得需求承诺●SP 1.3 管理需求变更●SP 1.4 维护需求的双向追溯性●SP 1.5 识别项目工作与需求间的差异REQM特定目标的关系SP 1.1 取得需求理解SP 1.1 和需求提出者一同来了解需求。
l 识别出谁是需求的提供者l 识别出需求的接受标准：a. Clearly and properly stated得到清晰和恰当的定义b. Complete完整的c. Consistent with each other相互一致的d. Uniquely identified得到唯一标识的e. Appropriate to implement适宜实现f. Verifiable (testable)可以验证（测试）g. Traceable可追溯l 分析需求，确保符合已建立的准则。
需求开发与管理标准化流程说明及表单书写说明全套
需求开发与管理标准化流程说明及表单书写说明1 目的定义需求开发与管理过程，为需求开发及跟踪提供有效的流程和方法。
2 适用范围2.1 机构研发中心技术部门及PMO、技术拓展部。
2.2 业务提供需求工程的过程标准。
3 名词术语3.1 RDM（Request Development and Management）：需求开发与管理。
3.2 SRS(Software Requirement Specification)：软件需求规格说明书。
3.3 客户(Customer)：开发产品订单的付费方3.4 最终用户(End User)：最终真正操作软件的用户3.5 用户需求：指直接来自于客户或者用户的原始需求3.6 产品需求：指对用户需求进行需求分析和开发之后生成的对于软件产品开发的需求3.7 CCB(Change Control Board)：变更控制委员会。
CCB的组长一般为适用机构的领导，成员一般为PMO及适用机构领导制定的某些特定人员，对于子部门级别的项目，CCB可直接由子部门的经理担任组长，由PMO担任组员。
4 概述项目在工程活动的开始，首先要进行需求开发。
后续所有的工程活动，包括设计、实现、测试均是根据需求展开的，所以需求开发的重要程度是最高的，而由于需求的抽象性，需求开发人员（系统分析员）既需要有过硬的专业知识，还要具备较强的交流、沟通能力，所以需求开发也是最难的。
任何项目，需求在整个工程开发过程中必定会发生变化，因此对需求变更的控制，即需求管理必不可少。
5 过程定义5.1 需求开发与管理5.1.1 角色与职责5.1.2 入口准则◆项目已经启动；◆对于合同项目，合同已经签订。
5.1.3 输入◆项目计划5.1.4 过程活动1)、需求调查获取用户（客户和最终用户）的需求信息。
调查需求的方式包括：◆与用户交谈，向用户提问题◆参观用户的工作流程，观察用户的操作◆向用户群体发调查问卷◆与同行。
专家交谈，听取他们的意见◆分析已经存在的同类软件产品，提取需求◆从行业标准、规则中提取需求◆从internet上搜查相关资料在需求调查完成之后，需要生成需求搜集的文档，文档形式可以自定义，但搜集的需求形成的文档需要由项目经理组织进行非正式的评审，要尽最大努力使搜集到的需求正确无误的反映用户的真实意愿。
需求管理的流程和步骤
需求管理的流程和步骤需求管理是指在项目或产品开发过程中，对需求进行有效管理和控制的一系列流程和步骤。
它确保项目团队和利益相关者对需求的理解一致，以便能够按照既定目标和计划开展工作。
下面将按照流程和步骤的顺序，详细介绍需求管理的过程。
一、需求收集需求收集是需求管理的第一步。
在这一阶段，项目团队需要与利益相关者进行沟通，了解他们的需求和期望。
可以采用面谈、问卷调查、座谈会等方式收集需求信息。
此外，还可以参考类似项目的经验教训，以及行业标准和法规等，获取更全面的需求。
二、需求分析需求分析是将收集到的需求进行分析和整理，以便更好地理解需求的本质和特点。
在这一过程中，项目团队需要将需求进行分类、去重、细化，并与项目目标进行对比和验证。
同时，还需要与利益相关者进行反复确认，确保对需求的理解无误。
三、需求规划需求规划是将需求分解为可管理的任务和阶段，以便更好地组织和跟踪工作进展。
在这一过程中，项目团队需要制定需求开发计划、分配工作任务、确定需求优先级等。
同时，还需要考虑资源和时间的限制，确保需求开发能够按计划进行。
四、需求跟踪需求跟踪是对需求开发和实现过程进行监控和管理，以确保项目进展按照预期进行。
在这一过程中，项目团队需要记录需求状态、更新需求进展、追踪需求变更等。
通过及时跟踪需求，可以及早发现和解决问题，避免需求漏掉或失控。
五、需求验证需求验证是对已开发的需求进行确认和验证，以确保需求符合利益相关者的期望和要求。
在这一过程中，项目团队需要与利益相关者进行沟通和协商，确认需求的准确性和完整性。
同时，还需要进行需求测试和评估，确保需求能够满足项目目标和质量要求。
六、需求变更管理需求变更管理是对需求变更进行控制和管理，以确保变更能够被合理地评估、决策和实施。
在这一过程中，项目团队需要建立变更管理流程和机制，明确变更的提交、审批和实施程序。
同时，还需要评估变更对项目目标、进度和成本的影响，做出明智的决策。
七、需求文档管理需求文档管理是对需求文档进行管理和控制，以确保需求文档的准确性、可靠性和可追溯性。
需求开发与管理规范
需求工程规范
一、软件特征
① 复杂性：人脑功能的加强与延伸 ② 难以描述性：自然语言的二义性导致难以表达 ③ 不可见性：无形的，存在于各种存储介质中 ④ 变化性：代码的修改引起功能的变化
发现问题并求精的过程；
需求定义的结果
进一步准确无误Байду номын сангаас定义产品需求；
四、加强需求管理力度
需求评审（分阶段分层次进行评审）
目标性需求：定义系统要达到的目标； 功能性需求：定义系统必须完成的任务； 操作性需求：定义任务的具体人机交互；
需求跟踪
登记需求功能点，并在设计、编码、测试的各环节追踪其实现位置 （需求跟踪矩阵法）；
需求变更控制
按照变更控制流程，通过变更单清晰定义变更内容，越精确定义需 求，越能避免需求的渐变，减少变更误解，做到变更的可控性与有 益性；（变更单+评审相结合，配置管理上辅助实施） 变更策略：项目启动后，进入需求基线前，侧重变更的清晰定义； 项目进入设计及之后的实施阶段，侧重变更的可控性与必要性；
五、附件一：需求阶段规范产物
需求规格说明书（模板暂未定） 需求跟踪矩阵 需求变更管理表(含变更单)
六、附件二：需求变更流程
软件需要不断的改变原因：1，2，3
二、软件常见开发问题
① 低质量：可能存在各种错误 ② 进度难以控制：不断提出新要求、需求不断变更 ③ 难以维护：缺陷难以定位、错误难以改正、功能 难以扩充、编码难以修改
三、加强需求分析力度
需求分析的目的
消除模糊性、歧义性和不一致性、分析数据要求，建立逻辑模型；
需求分析的任务
需求挖掘与需求管理
需求挖掘与需求管理在软件开发和项目管理过程中，需求挖掘与需求管理是确保项目成功的重要环节。
本文将介绍需求挖掘与需求管理的关键步骤和方法，包括需求收集、需求分析、需求优先级、需求规格、需求文档化、需求变更管理、需求验证与确认以及需求报告与评估。
1.需求收集需求收集是了解和获取项目需求的过程。
在这个阶段，我们需要尽可能多地收集来自利益相关者的意见和反馈，包括用户、客户、开发团队、管理人员等。
常用的需求收集方法包括问卷调查、访谈、观察、焦点小组等。
2.需求分析收集到足够的需求后，我们需要对它们进行分析，以理解需求的真实含义和意图。
这包括对需求进行分类、筛选、合并和分解，以确保团队对需求有一个清晰的认识。
此外，我们还需确定哪些需求是项目的核心需求，哪些是次要需求。
3.需求优先级在理解了所有需求之后，我们需要根据项目的目标和资源限制，为这些需求确定优先级。
优先级高的需求通常是那些对项目成功至关重要的需求，而优先级低的需求可能是一些额外的功能或改进。
4.需求规格在确定了需求的优先级之后，我们需要编写需求规格说明书，以详细描述每个需求的功能、性能、接口和其他约束条件。
这不仅有助于开发团队明确开发目标，还可以作为后续开发的依据。
5.需求文档化将需求规格编写成文档是至关重要的步骤。
文档应清晰、准确、易于理解，并包括所有相关的细节和背景信息。
此外，文档还应该具有可追溯性，以便团队在后续阶段可以轻松地跟踪和管理每个需求的来源和演变。
6.需求变更管理在项目执行过程中，可能会出现一些变更请求，例如用户或利益相关者要求添加新功能或修改现有功能。
这时，我们需要及时响应这些变更请求，评估其对项目的影响，并按照规定的流程进行审批和执行。
有效的需求变更管理可以提高项目的灵活性和应对能力。
7.需求验证与确认在开发过程中，我们需要定期对已实现的需求进行验证和确认，以确保开发团队按照原始需求规格进行开发。
这可以通过测试、用户验收或其他审查方式来实现。
如何进行需求管理经验、方法、模型、工具(一)
如何进行需求管理经验、方法、模型、工具（一）引言概述：需求管理是产品开发和项目管理的关键环节。
它涉及了从需求的收集、分析、优先级排序到需求确认和跟踪等一系列活动。
本文将围绕需求管理的经验、方法、模型和工具展开，为读者提供全面的指导。
一、需求收集1.1 用户访谈：通过与用户面对面交流，了解他们的需求和期望。
1.2 观察法：观察用户在日常生活中的行为和反馈，获取隐性的需求信息。
1.3 市场调研：通过市场调研了解行业趋势和竞争对手的产品，获取市场需求。
二、需求分析2.1 需求分类：将收集到的需求进行分类，便于后续的处理和分析。
2.2 需求描述：明确需求的特征、功能、性能等详细描述，确保理解一致。
2.3 需求分解：将高层次的需求细化为更为具体和可实现的子需求。
2.4 需求优先级排序：根据项目目标和优先级指标，对需求进行排序和分级。
2.5 需求确认：与相关利益相关者核实需求的准确性和完整性。
三、需求跟踪3.1 需求变更管理：建立需求变更管理流程，确保所有变更都经过审批和记录。
3.2 需求跟踪矩阵：建立需求与其他项目工作的追踪矩阵，确保需求的实现和追踪。
3.3 需求版本控制：对需求进行版本控制，确保能够追踪需求的变更历史。
3.4 需求追踪工具：使用需求追踪工具帮助管理和跟踪需求的变更和状态。
3.5 需求审查: 在项目中定期进行需求审查，确保需求的准确性和完整性。
四、需求管理模型4.1 Kano模型：通过满意度和重要性评估需求，将其划分为基本要素、期望要素和魅力要素。
4.2 MoSCoW模型：将需求分为必须有、应该有、可选有和不予以实现，以指导需求的优先级排序。
4.3 V模型：将需求管理的每个阶段与相应的测试阶段相匹配，确保需求的正确实现。
4.4 产品路线图：制定产品的长期发展计划，将需求与战略目标相联系。
4.5 敏捷开发：采用迭代和增量开发的方法，快速响应需求变化和提供业务价值。
五、需求管理工具5.1 需求管理软件：例如JIRA、TFS等，用于需求收集、追踪和变更管理。
软件需求分析与管理的实践经验分享
软件需求分析与管理的实践经验分享随着信息技术的不断发展，软件作为一种重要的工具和产品，越来越成为现代社会的基础设施。
软件产品的质量和效率，往往取决于软件开发过程中的需求分析和管理。
作为一名软件项目开发人员，我在长期的实践中积累了一些有益的经验，现在就和大家分享一下。
需求分析阶段软件开发的第一步，是需求分析阶段。
这一阶段的主要任务是明确软件产品需要实现的功能，以及用户需求和业务流程。
在这个过程中，有以下需要注意的地方：1.与用户沟通：向用户了解需求，协商业务流程，是需求分析的核心。
需要注意的是，与用户沟通需要耐心细致，并且对用户的需求做出适当的引导和规范。
有时候用户提出的需求不一定是最好的解决方案，需要我们根据自己的专业知识提出更好的建议。
2.规范需求文档：在需求分析阶段，需要输出一份需求文档，这份文档必须规范明确，确保每个需求条目都包含完整的信息。
需要注意的是，需求文档中应该尽量避免使用模糊或者歧义的术语，否则可能会导致后续开发出现偏差或失误。
3.注重可行性分析：需求分析不仅要考虑用户需求，还要考虑项目的可行性和成本效益。
需求分析师需要对项目的技术、人员和资源情况有一定的了解，确保提出的需求能在预算和时间范围内实现。
同时，在需求分析的过程中，还需要对具体的业务流程进行分析，确保提出的需求能够符合实际操作的要求。
4.注重需求的变更控制：软件需求是动态变化的，需要采取一定的变更控制措施。
在需求变更的时候，需要对变更内容进行评估，并且及时更新需求文档，同时也需要确保变更后的需求与其他模块的需求不发生冲突。
需求管理阶段需求管理是软件开发的一个重要环节。
在这个阶段，我们需要进行需求跟踪、需求评审、需求变更等管理工作。
以下是我在需求管理方面的一些经验：1.建立需求跟踪矩阵：需求跟踪矩阵是一个重要的工具，它可以帮助我们追踪不同版本的需求状态，并且清楚地了解每个需求的实现情况和质量。
在建立需求跟踪矩阵的时候，需要清晰地定义需求状态、进展情况，并且与需求文档保持同步更新。
系统开发的需求与管理分析报告
系统开发的需求与管理分析报告需求与管理分析报告一、引言系统开发是指通过对组织、业务流程和信息流程进行分析，设计和实施，从而达到提高效率、降低成本和改进服务质量的目标。
本报告旨在对系统开发过程中的需求与管理进行分析，旨在帮助项目团队更好地理解需求与管理的重要性，并提出相应的解决方案。
二、需求分析需求分析是系统开发的核心环节，是确定系统功能、性能、界面等各个方面需求的过程。
需求分析的主要任务是收集、分析、确认和管理系统的需求，确保开发的系统能够满足用户的期望和要求。
1. 收集需求在收集需求的过程中，需要与用户进行充分的沟通和交流。
可以通过座谈会、访谈、问卷调查等方式收集用户的需求，并根据用户反馈进行整理和归纳。
此外，还可以借助专业的需求调研工具和技术，如原型设计、用户故事等，来更好地理解用户需求。
2. 分析需求在分析需求的过程中，需要对用户提出的需求进行梳理和筛选。
对于冲突的需求，需要与用户进行深入探讨，寻找合理的解决方案。
同时，要对需求进行分类、划分优先级，并进行可行性分析和风险评估，以便制定合理的开发计划。
3. 确认需求在确认需求的过程中，需要与用户进行验收，确保开发的系统满足用户的期望和要求。
可以通过原型演示、评审会议等方式进行需求确认，及时修订和调整需求文档，并与用户签署正式的需求确认书。
三、管理分析需求管理是系统开发过程中的重要环节，是确保系统开发顺利进行的关键。
需求管理的主要任务是制定、执行和监控需求管理计划，确保开发的系统能够按时、按质量要求完成。
1. 制定需求管理计划在制定需求管理计划时，需要明确需求管理的目标、范围、工作流程和方法。
要制定合理的时间安排、资源分配和风险控制措施，确保需求管理工作的顺利进行。
2. 执行需求管理计划在执行需求管理计划的过程中，需要确保需求的变更与控制，及时回应用户的需求变更，并评估变更的影响和风险。
同时，要对需求文档进行版本控制和配置管理，确保开发的系统与需求文档一致。
软件开发过程中的需求管理
软件开发过程中的需求管理在软件开发过程中，需求管理是非常重要的一环。
通过合理的需求管理，可以提高软件开发的效率、降低风险，并最终实现客户期望的软件产品。
本文将着重探讨软件开发过程中的需求管理方面，包括需求收集、需求分析、需求验证和变更管理等。
一、需求收集需求收集是软件开发的第一步。
在这一阶段，软件开发团队需要与客户进行充分的沟通，了解客户的需求和期望。
通过面对面的会议、访谈、问卷调查等方式，收集客户的需求。
同时，也可以借助市场调研和竞争对手分析等手段，补充阳光不足。
二、需求分析需求分析是将收集到的需求进行整理、分类和理解的过程。
开发团队需要仔细研读收集到的需求文档，确保全面准确地理解客户的需求。
在需求分析的过程中，团队成员可以运用工具和方法，如用例图、状态图、数据流图等，对需求进行清晰的表达和梳理。
同时，需求分析还可以帮助发现潜在的需求冲突和矛盾，及时进行调整和沟通。
三、需求验证需求验证是确保开发团队理解准确的需求是关键步骤。
在这一阶段，需要制定一套明确的验证方案，确保软件的开发符合客户的需求和预期。
常用的验证方法包括原型验证、测试验证和用户验收验证等。
通过验证过程，可以发现并修正之前可能存在的误解和偏差，确保需求的准确性和可行性。
四、需求变更管理需求在软件开发过程中是可以变更的，因此，需求变更管理就显得至关重要。
在软件开发过程中，几乎所有的变更都会带来影响，包括时间、成本和资源等方面。
因此，需要建立一套规范的变更管理流程，明确变更的原因、影响和后果。
并且，变更管理流程需要与需求验证和项目管理相结合，确保需求的变更能够得到妥善的处理和控制。
五、需求文档管理需求文档是需求管理的重要组成部分。
在软件开发过程中，需求文档记录了需求的收集、分析、验证和变更等过程，也是需求沟通和交流的重要工具。
因此，需求文档需要规范、清晰地记录需求的内容和约束，并且需要根据实际情况进行定期更新。
六、需求管理工具和技术随着软件开发的不断发展，需求管理工具和技术也在不断更新。
软件开发项目中的需求分析与管理
软件开发项目中的需求分析与管理在软件开发项目中，需求分析与管理是确保项目成功的关键环节之一。
通过准确地识别和管理项目需求，能够有效地指导开发过程，并最终实现用户期望的功能。
本文将着重讨论软件开发项目中的需求分析与管理。
一、需求分析需求分析是指在软件开发项目初期，通过对用户需求进行认真研究和分析，明确项目的功能和性能要求。
需求分析的效果直接影响项目的后续开发和交付过程，因此需要详细而准确地进行。
1.用户需求的收集用户需求的收集是需求分析的第一步。
开发团队通过与用户、客户沟通，了解他们对软件产品的期望和要求。
这可以通过会议、访谈、问卷调查等方式进行。
在需求收集过程中，开发团队需要尽可能确保获取到全面和详细的需求信息。
2.需求的分类与整理收集到的需求信息需要进行分类与整理。
将需求按照功能、性能、安全性等方面进行划分，构建需求的分类体系。
这样可以更好地理解和组织需求，为需求的分析和管理提供支持。
3.需求的分析和详细化在需求分析阶段，开发团队需要对收集到的需求进行详细的分析和梳理。
通过与用户、客户的进一步沟通，澄清需求的不明确之处，并尽可能将需求细化为明确、可执行的指标。
需求的详细化有助于后续开发过程的顺利进行。
二、需求管理需求管理是指在软件开发项目中，对需求进行有效的组织、监控和调整的过程。
通过需求管理，可以提高项目的可控性和开发效率，避免开发过程中的需求变更和偏差。
1.需求的优先级规划在需求管理过程中，开发团队需要根据用户需求的重要性和紧迫性，制定需求的优先级规划。
将需求分为高、中、低优先级，有助于指导开发工作的安排和调整。
高优先级的需求应该优先考虑，以确保核心功能的实现。
2.需求的变更控制在开发过程中，用户对需求的变更是常见的情况。
因此，需求的变更控制也是需求管理的重要内容之一。
开发团队需要建立变更控制机制，对需求变更进行评估和审批，避免无效的变更和对开发进度的不利影响。
3.需求的跟踪和验证需求的跟踪和验证是确保项目进展顺利的关键环节。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第1章C M M I综述第1章CMMI综述·2·1.1CMMI简介 (3)1.1.1 CMMI发展简史 (4)1.1.2 CMMI的过程域 (5)1.1.3 CMMI的两种表示法 (6)1.2CMMI阶段式表示法 (7)1.2.1 成熟度等级L1：初始级的特征 (8)1.2.2 成熟度等级L2：已管理级的特征 (8)1.2.3 成熟度等级L3：已定义级的特征 (9)1.2.4 成熟度等级L4：量化管理级的特征 (9)1.2.5 成熟度等级L5：持续优化级的特征 (10)1.3CMMI连续式表示法 (10)1.3.1 能力等级0-不完整级的特征 (11)1.3.2 能力等级1-已执行级的特征 (12)1.3.3 能力等级2-已管理级的特征 (12)1.3.4 能力等级3-已定义级的特征 (12)1.3.5 能力等级4-量化管理级的特征 (13)1.3.6 能力等级5-持续优化级的特征 (13)1.4过程域的部件及解释 (14)1.4.1 必需部件 (14)1.4.2 期望部件 (15)1.4.3 信息部件 (15)1.5CMMI评估 (16)1.5.1 CMMI评估要求 (16)第1章CMMI综述·3·1.5.2 CMMI标准评估方法SCAMPI (17)1.5.3 CMMI评估考虑事项 (17)1.6CMMI和CMM的比较 (18)1.6.1 CMMI与CMM的模型比较 (18)1.6.2 CMMI 与CMM 过程域比较 (19)1.6.3 CMMI 与CMM评估方法比较 (20)1.7CMM/CMMI在中国 (20)1.1 CMMI简介第1章CMMI综述·4·1.1.1 CMMI发展简史1981年，美国卡内基梅隆大学软件工程研究所（SEI），应美国联邦政府的要求开发了一种用于评价软件承包商能力并帮助其改善质量的方法。
Watts Humphrey将成熟框架带到了SEI并增加了成熟度等级的概念，将这些原理应用于软件开发，发展成为软件过程成熟度框架，它提供了一个评估软件开发过程的管理以及工程能力的标准。
1987年，基于Watts H umphery 等人的工作，SEI的Mark Pauk 等人建立了第一个CMM（Capability Maturity Model，能力成熟度模型），即软件CMM。
1993年，SEI 推出了CMM 1.1。
十几年来CMM的改进工作一直不断地进行，相继有多个学科领域的CMM模型问世：SE-CMM, SW-CMM, IPD-CMM等。
美国国防采购与技术办公室领导了一个由政府、企业和SEI的代表组成的团队开始开发一个CMM模型的集成框架，即CMMI（Capability Maturity Model Integration，能力成熟度模型集成）。
CMMI的基础源模型包括：软件CMM 2.0版本，EIA-731系统工程，以及IPD CMM (IPD) 0.98a版本。
2002年1月CMMI 1.1版本正式发布，立即被广泛采用。
Array图1-1 CMMI 1.2的三种模型2006年8月，面向开发的CMMI（CMMI-DEV 1.2）版本正式发布。
为了适应更加广泛的应用，SEI计划今后发布另外二种模型，分别是面向服务的CMMI（CMMI-SVC 1.2）和面向采购的CMMI（CMMI-ACQ 1.2）。
第1章CMMI综述·5·注：本书论述的CMMI是CMMI-DEV 1.2。
1.1.2 CMMI的过程域过程域（Process Area）是同属于某个领域而彼此相关的实践集合，当这些实践共同执行时，可以达到该领域过程改进的目标。
CMMI-DEV 1.2有22个过程域，见表1-1（按字母排序）。
第1章 CMMI 综述 ·6·表1-1 CMMI-DEV 1.2的22个过程域1.1.3 CMMI 的两种表示法CMMI 有两种表示法：一种是阶段式表示法；另一种是连续式表示法。
图1-2 CMMI 的阶段式表示法阶段式表示法把过程域分成5个成熟度等级，指出达到每一成熟度等级必须实施哪些过程域。
成熟度等级提供一个阶段式过程改进的建议顺序。
如图1-2所示，一个成熟度等级包括多个过程域，每个过程域包含共性目标和特定目标，以及共性实践和特定实践。
第1章CMMI综述·7·图1-3 CMMI的连续式表示法连续式表示法则将过程域分为四大类型：过程管理过程、项目管理过程、工程过程以及支持过程。
每类过程中的过程域又进一步分为“基础的”和“高级的”。
在按照连续式表示方法实施CMMI的时候，一个组织可以把项目管理或者其它某类的实践一直做到最好，而其它方面的过程区域可以不必考虑。
1.2 CMMI阶段式表示法成熟度等级是一组经过定义的渐进式过程改进指标，达到每个成熟度等级，则代表组织过程的某重要部分有了稳固的基础。
CMMI的阶段式表示法将成熟度划分为5个等级。
除了初始级以外，每个成熟度等级都有若干个过程域，如表1-2所示。
由于成熟度等级是循序渐进的，如果想达到某个成熟度等级，例如CMMI 3级，除了满足CMMI 3级本身11过程域之外，还要满足CMMI 2级的7个过程域，依此类推。
第1章CMMI综述·8·表1-2 CMMI阶段表示法：成熟度等级和过程域的关系表1.2.1 成熟度等级L1：初始级的特征在成熟度第1级中，过程通常是混乱的，而且组织通常没有提供稳定的开发环境。
这些组织的成功，往往依赖组织中个人的能力与拼搏精神，而不是使用一套经过验证的过程。
处于成熟度第1级的组织在这种混乱的环境中，也能开发出可以工作的产品和服务，但是往往伴随着项目费用超支和进度拖延。
1.2.2 成熟度等级L2：已管理级的特征在成熟度第2级中，组织已达到成熟度第2级所有过程域的特定目标和共性目标。
换言之，组织的项目已确保需求是被管理的，而且其过程是经过计划、执行、度量及控制的。
第1章CMMI综述·9·在成熟度第2级，需求、过程、工作成果及服务是受管理的。
在预定的时间节点（例如重要里程碑、重要的任务完成时刻），管理层都可以了解工作成果的情况。
1.2.3 成熟度等级L3：已定义级的特征在成熟度第3级中，组织已达到成熟度第2和第3级所有过程域的特定目标和共性目标，工作过程都已详尽地说明，并应用标准、规程、工具及方法来表现。
组织的标准过程（Organization’s set of standard process）是成熟度第3级的基础。
项目可对组织的标准过程进行裁剪，以建立项目过程。
成熟度第2级与第3级的主要区别在于标准、过程说明及规程的范围。
在成熟度第2级中，某过程在不同案例间的标准、过程说明及规程可能有相当的差异。
在成熟度第3级中，项目的标准、过程说明及规程都是从组织的标准过程裁剪而来的，以适用于某些特殊项目或单位。
组织的标准过程包括了成熟度第2级和第3级的过程，因此除了裁剪指南所允许的差异之外，整个组织所执行的过程都是一致的。
另一个主要的区别是，成熟度第3级的过程说明比第2级更加详细与严谨，基于对过程活动的了解，以及对过程、产品与服务的详细度量，可更主动地管理过程。
1.2.4 成熟度等级L4：量化管理级的特征在成熟度第4级中，组织已达到成熟度第2、第3和第4级所有过程域的特定目标和共性目标。
选定对整体过程绩效有重大影响的子过程，并使用统计和其他的量化技术来控制这些子过程。
建立质量与过程绩效的量化目标，并以该目标为管理过程的准则。
量化目标是根据客户、最终用户、组织及过程执行者的需求而设定。
以统计的术语表示质量和过程绩效，并在整个过程中受到管理。
针对这些过程，收集过程绩效的详细度量资料，并进行统计分析。
界定过程变化的特殊原因，并适当地修正特殊原因的来源，以避免未来再度发生。
将质量和过程绩效的度量结果，纳入到组织的度量库（organization’s measurement repository），以支持未来以事实为基础的决策。
成熟度第3级与第4级的主要区别在于过程绩效的可预测能力。
在成熟度第4级中，过程绩效是由统计和其它的量化技术所控制，并且可以用量化方式预测。
但在成熟度第3级中，仅能说在质量上是可预测的。
第1章CMMI综述·10·1.2.5 成熟度等级L5：持续优化级的特征在成熟度第5级中，组织已达到成熟度第2、第3、第4和第5级所有过程域的特定目标和共性目标。
根据对过程变化共性原因的量化了解，持续进行过程改进。
经由渐进式的和革新式的技术改进，成熟度第5级专注于持续改进过程绩效，已经建立组织的量化过程改进目标，并持续修订以反映持续变化的经营目标。
量化的过程改进目标也当作管理过程改进的准则，用以度量、评估已进行的过程改进效果。
已定义过程和组织标准过程都是这些可度量改进活动的对象。
通过查找问题，加快共享经验教训，可以增强组织对变化和机会的快速反应能力。
过程改进是每个人的责任，它也使得过程改进不断得到循环。
在成熟度第5级中，过程改进解决过程变化的共性原因，以及界定、评估和执行可度量的组织过程改进。
改进方案的选择，以下列二者的量化了解为基础：（1）过程改进方案对组织过程改进目标的预期贡献；（2）执行时的成本和对组织的影响。
成熟度第4级与第5级的主要区别在于所要克服的过程变化类型。
在成熟度第4级中，过程专注于克服特殊原因的过程变化，并提出统计上的可预测结果。
虽然过程或许可以产生预期的结果，但该结果不足以达到预期的目标。
在成熟度第5级，过程专注于克服过程变化的共性原因，并改变过程（也就是改变过程绩效的平均值）以改善过程绩效（同时维持统计上的可预测性），以便达到预期过程改进的量化目标。
1.3 CMMI连续式表示法能力等级（C apability Level）表示一个组织在实施和控制其过程以及改善其过程绩效等方面所具备的能力。
一个过程能力等级由这个过程的若干相关的特定实践和共性实践所构成。
这些特定实践和共性实践如果得以执行，则将使该组织的这个过程的执行能力得到提高，进而增强该组织的总体过程能力。
过程能力等级模型中的能力等级的着眼点在于使组织走向成熟，以便增加实施和控制过程的能力并且改善过程本身的绩效。
这些能力等级有助于组织在过程改进各个相关过程时追踪、评价和验证各项改进进程。
连续式表示法中，每个过程域的能力等级划分0~5级（共6级），从0~5编号，它们是：0 不完整级；1 已执行级；2 已管理级；3 已定义级；4 量化管理级；5 持续优化级。
CMMI模型的连续式表示，按照过程域之间的关系分成四个类型：过程管理过程、项目管理过程、工程过程和支持过程，如表1-3所示。