第6章软件测试
6.1 软件测试目标与软件测试过程模型
6.1.1 软件测试及目标 软件测试的定义为：
按照特定规程发现软件错误的过程。其目的是检验它是否满足规定的需求，或清楚了解预期结构与实际结果之间的差异。
6.1.2 软件测试与软件调试的区别 软件测试与软件调试相比，在目的、技术和方法等方面都存在很大区别，主要表现在以下几个方面。
(1)测试从一个侧面证明程序员的“失败”。调试是为了证明程序员的正确。
(2)测试以已知条件开始，使用预先定义的程序且有预知的结果，不可预见的仅是程序是否通过。调试一般是以不可知的内部条件开始，除统计性调试外，结果是不可预见的。
(3)测试是有计划的，并要进行测试设计。调试是不受时间约束的。
(4)测试是一个发现错误、改正错误、重新测试的过程。调试是一个推理过程。
(5)测试的执行是有规程的。调试的执行往往要求程序员进行必要推理。
(6)测试经常是由独立的测试组在不了解软件设计的条件下完成的。调试必须由了解详细设计的程序员完成。
(7)大多数测试的执行和设计可由工具支持。调试时，程序员能利用的工具主要是调试器。
6.1.3 测试过程模型 软件测试是一个有程序的过程，包括测试设计、测试执行以及测试结果比较。测试过程模型可分为三类：环境模型、被测对象模型和错误模型。
(1)环境模型：是对程序运行环境的抽象。程序运行环境又包括支持其运行的硬件、固件和软件，如计算机、终端设备、网卡、操作系统、编译系统、实用程序等。在软件测试过程中，建立环境模型的主要目的是，确定所发现的错误是否为环境造成的。
(2)被测对象模型：该模型是从测试的角度对程序的抽象。为了测试，必须简化程序，形成被测程序的抽象版本，即对象模型。
(3)错误模型：该模型是对程序中的错误及其分类的抽象。在软件测试中，往往需要定义“什么是错误”、“什么是一般性错误”、“什么是严重性错误”等，即要给出“错误模型”。
6.2 软件测试技术
6.2.1 测试覆盖及其它们之间的基本关系 软件测试技术大体上可分为两大类：
- 一类是白盒测试技术，又称为结构测试技术，典型的是路径测试技术；
- 另一类是黑盒测试技术，又称为功能测试技术，包括事务处理流程技术、状态测试技术、定义域测试技术等。
白盒测试技术依据的是程序的逻辑结构，而黑盒测试技术依据的是软件行为的描述。
6.2.2 路径测试技术的分类 测试覆盖包括路径覆盖、分支覆盖、条件覆盖与条件组合覆盖。
(1)路径覆盖：执行所有可能穿过程序控制流程的路径。在路径测试中，该度量是最强的，一般是不可实现的。
(2)语句覆盖：至少执行程序中所有语句一次。
(3)分支覆盖：至少将程序中的每一个分支执行一次。
(4)条件覆盖与条件组合覆盖。条件覆盖是指每个判定中的所有可能的条件取值至少执行一次；条件组合覆盖是指设计足够的测试用例，使每个判定中所有可能的条件取值组合至少执行一次。(第二强) 这四种测试覆盖的测试覆盖率由弱到强的顺序是：语句覆盖、分支覆盖、条件组合覆盖、路径覆盖。
6.2.3 事务流测试步骤
事务流测试步骤具体如下。
第一步：获得事务流程图。
第二步：浏览、复审。
第三步：用例设计。
第四步：测试执行。
6.2.4 运用等价类划分技术进行测试的步骤
等价类划分（Equivalence Partitioning）是一种黑盒测试技术，用于将输入数据划分为若干个等价类，以减少测试用例的数量，同时保证测试覆盖的有效性和全面性。等价类划分的基本思想是将输入数据划分为不同的类别，每个类别中的数据具有相同的测试行为和预期结果。
等价类划分的步骤如下：
- 分析需求：仔细分析被测系统的需求和功能规范，明确输入数据的要求和约束。
- 确定等价类：根据需求分析，将输入数据划分为若干个等价类。每个等价类包含具有相同测试行为和预期结果的输入数据。
- 选择测试用例：从每个等价类中选择一个或多个典型的测试用例，作为代表性的输入数据。通常选择边界值、特殊值和常见值等。
- 执行测试用例：使用选定的测试用例进行测试，验证系统的功能和性能是否符合预期。
- 验证结果：根据测试结果，判断系统的行为是否符合预期。如果测试通过，表示该等价类的测试覆盖有效；如果测试失败，表示该等价类的测试覆盖无效或不充分。
等价类划分的优势在于可以大大减少测试用例的数量，同时仍能保证测试覆盖的有效性。通过选择代表性的测试用例，能够覆盖各种情况，包括边界条件、异常情况和一般情况，从而有效地发现潜在的缺陷和问题。等价类划分是一种常用的测试设计技术，适用于各种软件系统的测试，特别是输入数据较多且复杂的场景。
具体测试步骤如下。
第一步：建立等价类表。
第二步：为有效等价类设计测试用例。
第三步：为无效等价类至少设计一个测试用例。
6.2.5 边界值分析的使用原则 边界值分析是一种常用的黑盒测试技术。使用边界值分析在设计测试用例时，可以遵循以下原则。
(1)如果某个输入条件规定了输入值的范围，则应该选择正好等于边界值的数据，以及刚刚超过边界值的数据作为测试数据。
(2)如果某个输入条件规定了值的个数，则可用最大个数、最小个数、比最大个数多1比最小个数少1的数据作为测试数据。
(3)根据规格说明的每个输出条件，使用前面的原则(1)。
(4)根据规格说明的每个输出条件，使用前面的原则(2)。
(5)如果程序的规格说明中，输入域或输出域是有序集合，在实践中则经常选取集合的第一个元素、最后一个元素以及典型元素作为测试用例。
(6)如果程序中使用了内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。
(7)分析规格说明，找出其他可能的边界条件。
6.2.6 使用因果图生成测试用例的步骤 因果图技术是通过为判定表的每一列设计一个测试用例，从而实现测试用例的设计与选择的。该方法生成测试用例的基本步骤如下。 (1)通过软件规格说明书的分析，找出一个模块的原因和结果,并给每个原因和结果赋予一个标识符。 (2)分析原因与结果之间以及原因之间对应的关系，并画出因果图。 (3)在因果图上标识出一些特定的约束或限制条件。 (4)把因果图转换成判定表。 (5)把判定表的每一列拿出来作为依据，设计测试用例。
6.3 软件测试步骤
软件测试的基本步骤 ：
(1)单元测试单元测试主要检验软件设计的最小单元——模块。该测试以详细设计文档为指导，测试模块内的重要控制路径。一般来说，单元测试往往采用白盒测试技术。
(2)集成测试集成测试是软件组装的一个系统化技术，其目标是发现与接口有关的错误，将经过单元测试的模块构成一个满足设计要求的软件结构。集成测试集中于模块组合的功能和软件结构检验。集成测试可“自顶向下”地进行，称为自顶向下的集成测试;也可以“自底向上”地进行测试，称为自底向上的集成测试。
(3)有效性测试有效性测试的目标是发现软件实现的功能与需求规格说明书不一致的错误。因此有效性测试通常采用黑盒测试技术。
(4)系统测试系统测试验证将软件融于更大系统中时整个系统的有效性。
第7章 软件生存周期过程与管理
7.1 软件生存周期过程概述
7.1.1 过程分类 按过程主体把软件生存周期过程分为以下几个过程。
(1)基本过程：是指那些与软件生产直接相关的活动集。该过程又可分为获取过程、供应过程、开发过程、运行过程和维护过程。
(2)支持过程：是指有关各方按他们的目标所从事的一系列相关支持活动集。该过程又可分为文档过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审过程、审计过程和问题解决过程。
(3)组织过程：是指那些与软件生产组织有关的活动集。该过程又可分为设计过程、基础设施过程培训过程和改进过程。
7.1.2 系统语境的过程类 系统语境的过程类包含四个过程组，分别是协议过程组、项目过程组、技术过程组和组织上项目使能过程组。
(1)协议过程组包含两个过程：获取过程和供应过程。
(2)项目过程组包含七个过程：:项目规划过程项目评价过程、决策管理过程、风险管理过程、配置管理过程、信息管理过程和测量过程。
(3)技术过程组包含11个过程：利益攸关方需求定义过程、系统需求分析过程、系统体系结构设计过程、实现过程、系统集成过程、系统测试过程、软件安装过程、软件接受支持过程、软件运行过程、软件维护过程和软件销毁过程。
(4)组织上使能过程组包含五个过程：生存周期模型管理过程、基础设施管理过程、项目包管理过程、人力资源管理过程和质量管理过程。
7.1.3 组织上使能过程的作用。 组织上使能的过程一般来说是组织层面上的工作，为项目的执行提供基本保障。该过程包含五个子过程。
(1)生存周期模型管理过程：其任务为过程建立、过程评估、过程改进。
(2)基础设施管理过程：其任务为过程实现、基础设施的建立、基础设施的维护。
(3)项目包管理过程：项目初始化、项目包评估、项目结束处理
(4)人力资源管理过程：其任务为技能标识、技能开发、技能获取和供给、知识管理。
(5)质量管理过程：其任务为质量管理、质量管理纠正措施。
7.2 过程描述
软件验证过程包含两个活动：过程实现和验证。 验证活动有五个任务：
- 需求验证
- 设计验证
- 代码验证
- 集成验证
- 文档验证
5个过程可通过过程意图、期望的结果以及达到过程结果所需要执行的活动和任务来描述。 对于一个过程的完整技术上的描述，还应包括：达到过程意图和实现过程结果的方法或规程，以及过程和活动的文档。
7.3 应用说明
7.3.1 系统和软件的关系
在《ISO/IEC系统与软件工程一软件生存周期过程12207-2008》标准中，把软件认为是整个系统的一个组成部分，执行系统中所确定的功能主要包括三大功能：
- 控制功能
- 耦合功能
- 软件本身提供的功能
由于软件通常存在于一个系统的上下文中，因此软件产品或服务一般可被认为是系统的一个项或称为系统元素。
7.3.2 剪裁过程及应用
剪裁过程是使剪裁这一标准过程满足以下特定情况或因
(1)围绕一个组织，其中该组织在一个协议中使用了这一标准。
(2)影响一个项目，其中要求该项目满足一个引用该标准的协议。
(3)反映一个组织的需要，其中该组织要供给产品或服务。
7.4 软件生存周期模型
7.4.1瀑布模型 瀑布模型是将软件生存周期各个活动规定为按固定顺序连接的若干阶段的模型。这模型规定了各开发阶段的活动：系统需求、软件需求、需求分析、设计、编码、测试和运行，并且自上而下具有相互衔接的固定顺序；还规定了每一阶段的输入，即工作对象以及本阶段的工作成果，作为输出传送到下一阶段。
△瀑布模型的提出，对软件工程的主要贡献为如下：
(1)在决定系统怎样做之前存在一个需求阶段，它鼓励对系统做什么进行规约。
(2)在系统构造之前存在一个需求阶段，它鼓励规划系统结构。
(3)在每一阶段结束时进行评审，从而允许获取方和用户的参与。
(4)前一步可以作为下一步被认可的、文档化的基线，并允许基线和配置早期接受控制。
瀑布模型的问题主要是：
(1)要求客户能完整、正确和清晰地表达他们的需求；并要求开发人员一开始就要理解这一应用。
(2)由于需求的不稳定性，使设计、编码和测试阶段都可能发生延期；并且当项目接近结束时，出现了大量的集成和测试工作。
(3)在开始的阶段中，很难评估真正的进度状态；并且直到项目结束之前都不能演示系统的能力。
(4)在一个项目的早期开发阶段，过分地强调了基线和里程碑处的文档；并可能需要花费更多的时间用于建立一些用处不大的文档。
7.4.2 增量模型 增量模型是一种非整体开发的模型。软件在该模型中逐渐开发出来，开发出一部分，可让用户及早看到部分软件，及早发现问题。该模型具有较大的灵活性，适合于软件需求不明确、设计方案有一定风险的软件项目。
7.4.3 演化模型 该模型主要针对事先不能完整定义需求的软件开发的。 在用户提出待开发系统的核心需求的基础上，软件开发人员按照这一要求，
1.首先开发一个核心系统并投入运行,以便用户能够有效地提出反馈，即精化系统、增强系统能力的需求；
2.接着，软件开发人员根据用户反馈，实施开发的迭代过程；
3.每一迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集；
4.如果在一次迭代中，有的需求不能满足用户的要求，可在下一次迭代中予以修正。
主要特征：该模型显式地把需求获取扩展到需求阶段，即为了第二个构造增量，使用了第一个构造增量来精化需求。演化模型在一定程度上可以减少软件开发活动的盲目性。不足之处：在演化模型的使用中，即使很好地理解了需求或设计，也很容易弱化需求分析阶段的工作。
7.4.4 螺旋模型螺旋模型
将瀑布模型与增量模型结合起来，加入了两种模型均忽略了的风险分析，弥补了这两种模型的不足。因而它是一种风险驱动的模型。
螺旋模型将开放过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合。 螺旋模型关注解决问题的基本步骤，即标识问题，标识一些可选方案，选择一个最佳方案，遵循动作步骤并实施后续工作。
其一个突出特征是,在开发的迭代中实际上只有一个选代过程真正开发了可交付的软件。 螺旋模型与演化模型和增量模型相比，同样适用了瀑布模型作为一个嵌入的过程，但螺旋模型所关注的阶段以及它们的活动是不同的。
如果项目的开发风险很大或客户不能确定系统需求，在更广泛的意义上来讲，还包括一个系统或系统类型的要求，这时螺旋模型就是一个好的生存周期模型。
在实际应用中，螺旋模型的每个迭代通常都会产生一些可交付的软件。然而，只有一个迭代会被认为是主要的开发阶段，这意味着在这个阶段中，软件的大部分功能和特性都会被开发和交付。其他迭代则可能是在此基础上进行改进和修复bug。
这种做法是为了在开发过程中更好地管理风险。通过先开发和交付一个可行的软件产品，团队可以在后续的迭代中根据用户反馈和需求变化进行调整和优化。这种迭代的方法可以减少项目失败的风险，并提高软件的质量和用户满意度。
7.4.5 喷泉模型
喷泉模型体现了软件创建所固有的迭代和无间隙的特征。该模型主要用于支持面向对象技术的软件开发。由于对象概念的引人，使分折、设计、实现之间的表达没有明显间隙。
7.5 过程规划与管理
7.5.1 创建一个软件项目生存周期过程的步骤
(1)选择软件生存周期模型。
(2)细化所选择的生存周期模型。
(3)为每一个活动或任务标识合适的实例数目。
(4)确定活动的时序关系,并检查査信息流。
(5)建立过程计划的文档。
7.5.2 软件评估
软件评估中应考虑的影响因素不管做什么样的决策，都必须对所采取的措施对生存周期过程所产生的影响进行评审，以便保证项目获得好的结果。在这一评估中,应考虑以下几方面的影响。
(1)所要求的“返工”。
(2)资源需求。
(3)实施时间。
(4)对项目和用户的益处。
(5)员工情绪。
第8章集成化能力成熟度模型(CMMI)
CMMI（Capability Maturity Model Integration）是一种用于评估和改进组织的软件和系统工程能力的框架。它是由美国软件工程协会（SEI）开发的，旨在帮助组织提高其软件和系统工程实践的成熟度水平。
CMMI是一种成熟度模型，它描述了一个组织在软件和系统工程领域的成熟度水平。成熟度水平是通过评估组织的过程能力来确定的，包括组织的过程管理、工程能力和项目管理等方面。CMMI通过定义一组最佳实践和指南来帮助组织改进其过程和实践，从而提高其成熟度水平。
CMMI的框架包括不同的成熟度级别，从初始级别到最高级别依次为：初始级别、已管理级别、已定义级别、已量化管理级别和已优化级别。每个级别都有一组特定的目标和实践，组织可以根据自身需求和目标选择适合的级别进行改进。
CMMI的应用可以帮助组织实现以下目标：
- 提高软件和系统工程过程的可预测性和稳定性。
- 提高软件和系统工程过程的质量和效率。
- 降低项目失败的风险。
- 改进组织的绩效和竞争力。
8.1 背景和原理
8.1.1 过程改善
历史过程改善，是指人为设计的一个活动程序，其目的是改进组织的过程性能和成熟度，并改进这一程序的结果。
8.1.2 过程专用目标和共用目标过程域
是一个业务域中一束相关的实践，当它们一起得以实现时，就满足被认为对该过程域的改善具有重要作用的一组条件。
专用目标是用于描述满足该过程域必须呈现的一些独有特征。经可以用于帮助确定一个过程域是否得以满足。
共用目标用于描述呈现制度化的该过程必须呈现的特征，仅用于确定一个过程域是否得以满足。
CMMI（能力成熟度模型集成）中的过程域是指软件开发过程中的不同领域或方面。它们代表了软件开发过程中的关键活动和任务。每个过程域都涵盖了一组与该领域相关的最佳实践和活动，以确保高质量的软件开发。
CMMI将软件开发过程分为多个过程域，例如需求管理、配置管理、项目计划等。每个过程域都有特定的目标和实践，通过遵循这些实践，组织可以提高其软件开发过程的成熟度和效率。
过程域的存在帮助组织建立一套系统化的软件开发过程，并提供了一种评估和改进这些过程的方法。它提供了一种框架，帮助组织识别和改进软件开发过程中的短板，并根据最佳实践来提高开发过程的成熟度和质量。
过程域：
CMMI（能力成熟度模型集成）目前共有22个过程域（16+6），它们分为两个类别：能力级别和成熟度级别。
- 在能力级别，CMMI有16个过程域，它们用来衡量和评估组织在特定领域的能力水平。这些过程域包括：
- 配置管理（Configuration Management）
- 决策分析和解决（Decision Analysis and Resolution）
- 需求开发（Requirements Development）
- 需求管理（Requirements Management）
- 技术解决方案（Technical Solution）
- 项目监控（Project Monitoring and Control）
- 项目计划（Project Planning）
- 项目质量管理（Process and Product Quality Assurance）
- 量度和分析（Measurement and Analysis）
- 组织过程定义（Organizational Process Definition）
- 组织过程焦点（Organizational Process Focus）
- 组织培训（Organizational Training）
- 组织绩效管理（Organizational Performance Management）
- 风险管理（Risk Management）
- 供应商协议管理（Supplier Agreement Management）
- 集成项目管理（Integrated Project Management）
- 在成熟度级别，CMMI有6个过程域，它们用来评估和改进整个组织的成熟度水平。这些过程域包括：
- 识别（Identification）
- 评估和决策（Decision-Making and Evaluation）
- 定义（Definition）
- 量化过程管理（Quantitative Project Management）
- 核心项目管理（Core Project Management）
- 产品集成（Product Integration）
这些过程域涵盖了软件开发过程中的不同方面和领域，帮助组织评估和改进其能力和成熟度，以提高软件开发过程的效率和质量。
目标
在CMMI（Capability Maturity Model Integration）过程域中，专用目标和共用目标是指不同过程域中的目标。
专用目标是指在特定的过程域中，针对该过程域的特定需求或目标所设定的目标。专用目标主要关注该过程域的特定要求和目标，以提高该过程域的能力和效率。
共用目标是指在多个过程域中共同适用的目标。这些目标通常是为了促进组织整体的协同合作、质量管理和持续改进而设定的。共用目标强调各个过程域之间的协同和配合，以实现整体的业务目标和质量要求。
确定一个目标是专用还是共用，可以考虑以下几个因素：
- 目标的适用范围：如果目标仅适用于特定的过程域，那么它更可能是专用目标。如果目标适用于多个过程域，那么它更可能是共用目标。
- 目标的关联性：如果目标与特定过程域中的特定需求和目标紧密相关，那么它更可能是专用目标。如果目标与多个过程域之间的协同合作和整体业务目标相关，那么它更可能是共用目标。
- 目标的制定过程和参与者：如果目标是由特定过程域的相关利益相关者制定，并且只关注该过程域的要求，那么它更可能是专用目标。如果目标是由多个过程域的相关利益相关者共同制定，并且考虑到整体的协同和质量要求，那么它更可能是共用目标。
综上所述，专用目标主要关注特定过程域的要求和目标，而共用目标强调多个过程域之间的协同和整体业务目标。要确定一个目标是专用还是共用，需要考虑目标的适用范围、关联性和制定过程和参与者。
8.2 CMMI的模型部件
CMMI模型中有22个过程域,分为4个类,见表8-1。 表8-1：CMMI的过程域
过程域类名 |
包括的过程域 |
项目管理类 |
项目规划、项目监控、定量项目管理、集成项目管理、风险管理、提供方协议管理 |
工程类 |
需求开发、需求管理、技术解决方案、产品集成、确认、验证 |
支持类 |
配置管理、过程和产品质量保证、测量与分析、原因分析与解决、决策分析与解决 |
过程管理类 |
组织过程定义、组织过程性能、组织过程培训、组织过程关注、组织创新与部署 |
8.3 CMMI的等级
8.3.1 能力等级的组成 能力等级是用来表征组织对一个过程域的改善，是不断改善一个给定过程域的一种手段。在CMM中，针对每个过程域设定了6个能力等级，即：
- 0级：未完成级；
- 1级：已执行级；
- 2级：已管理级；
- 3级：已定义级；
- 4级：已定量管理级；
- 5级：持续优化级。
8.3.2 成熟度等级的组成 在CMMI中，应用于一个组织过程改善的成熟度等级有5个。即
- 1级：初始级；
- 2级：已管理级；
- 3级：已定义级；
- 4级：已定量管理级；
- 5级：持续优化级。
8.3.3 能力等级与成熟度等级之间的基本关系 能力等级与成熟度等级是互补的关系，两者都是一种过程改善路径，其中：
(1)能力等级的路径可使组织针对单一过程域不断改善该过程域，即表征组织对单过程域的改进。
(2)成熟度等级的路径可使组织通过关注一个过程域不断改善一组相关过程域，即表征组织对一组过程域的改进。
(3)两种等级的2-5级使用了同样的名字。
8.3.4 达到各共用目标所要实施的共同实践
达到共用目标2、共用目标3、共用目标4和共用目标5所要实施的共同实践如下表所示。
目标 |
所要实施的共用实践 |
共用目标2:把过程制度化为一个管理过程 |
GP2.1建立组织策略，GP2.2规划过程，GP2.3提供资源，GP2.4指派责任，GP2.5培训人员，GP2.6管理配置，GP2.7标识相关利益方的参与，GP2.8监控过程，GP2.9客观地评估符合性，GP2.10从高层管理的视觉评审状态 |
共用目标3:把过程制度化为一个已定义过程 |
GP3.1建立一个已定义的过程，GP3.2收信进信息 |
共用目标4:把过程制度化为一个已定量管理过程 |
GP4.1为该过程建立定量目的，GP4.2使子过程性能达到稳定 |
共用目标5:把过程制度化为一个持续优化过程 |
GP5.1确保不断进行过程改善，GP5.2收集问题的根本原因 |
8.4 CMMI是如何帮助组织进行过程改善的
改善步骤
CMMI通过以下步骤帮助组织进行过程改善：
- 确定改进目标：组织需要明确其改进的目标和需求。这可能包括提高质量、降低成本、提高效率等方面的目标。
- 评估现状：组织需要评估当前的软件和系统工程过程的成熟度水平。这可以通过CMMI的评估方法来进行，包括自我评估、内部评估或第三方评估。
- 识别改进机会：基于对现状的评估，组织可以识别出需要改进的领域和机会。这可能包括缺失的最佳实践、过程中的瓶颈或问题等。
- 制定改进计划：组织需要制定一个详细的改进计划，包括确定改进的重点、制定具体的行动计划和资源分配。
- 实施改进措施：组织需要根据改进计划，实施具体的改进措施。这可能涉及到培训员工、制定和实施新的过程、引入工具和技术等。
- 监控和测量改进效果：组织需要建立适当的度量和监控机制，以评估改进措施的效果。这可以通过收集和分析数据、进行内部审查和评估等方式来进行。
- 持续改进：改进是一个持续的过程，组织需要不断地跟踪和调整改进计划，以确保持续改进的实施和成功。
值得注意的是，CMMI并不是一种具体的方法论或解决方案，而是一个框架，提供了一组最佳实践和指南。因此，具体的过程改善方法和实施方式可能因组织的需求和情况而异。组织可以根据CMMI的指导，结合自身的实际情况，制定适合自己的过程改善计划。
评估方法
CMMI的评估方法主要包括以下几种常见的方法：
- 自我评估（SCAMPI A）：组织内部的评估团队根据CMMI的指南和要求，自行进行评估。这种方法适用于组织想要了解自身在CMMI模型中的成熟度水平和改进机会，但不需要正式的认证或认可。
- 内部评估（SCAMPI B）：由组织内部或外部的评估团队进行的评估。这种评估通常由经过培训和授权的评估人员进行，可以提供更独立和客观的评估结果。内部评估可以用来确定组织的成熟度水平和改进机会，并为组织提供有关改进计划和行动的建议。
- 外部评估（SCAMPI C）：由独立的第三方评估机构或认证机构进行的评估。这种评估通常用于组织希望获得CMMI认证或认可的情况。外部评估需要按照CMMI模型和评估方法的要求进行，评估结果会被认证机构进行审核和认可。
除了上述常见的评估方法，CMMI还提供了一些其他的评估方法和工具，如基线评估（Baseline Appraisal）、过程能力评估（Process Capability Appraisal）等。这些方法和工具可以根据组织的需求和目标进行选择和应用。
无论采用哪种评估方法，评估团队都需要对CMMI模型的要求和指南进行深入理解，并按照评估方法的规定进行评估活动。评估结果可以帮助组织了解自身的软件和系统工程能力，识别改进机会，并制定相应的改进计划和措施。
改善计划
制定一个CMMI改善计划通常涉及以下步骤：
- 确定改善目标：明确组织希望通过CMMI改善计划实现的目标。这些目标可以包括提高过程质量、提高工程能力、降低成本、提高项目交付效率等。
- 评估现状：通过自我评估或其他评估方法，评估组织当前的CMMI成熟度水平和过程能力。这将帮助确定当前存在的缺陷和改进机会。
- 选择改进领域：根据评估结果，确定需要改进的具体领域和过程。这可以是在CMMI模型中的特定领域，如需求管理、配置管理、项目管理等，也可以是组织内部已经识别的问题领域。
- 设定优先级和时间表：根据改进目标和改进领域的重要性和优先级，制定一个改进计划的时间表。确定改进计划的阶段性目标和时间节点。
- 制定行动计划：为每个改进领域制定具体的行动计划。这包括确定需要采取的具体措施、分配责任和资源、设定衡量指标等。
- 建立改进团队：组织一个专门的改进团队来负责推动和实施CMMI改善计划。这个团队应该由具有相关知识和经验的成员组成，并具备推动变革和改进的能力。
- 实施改进措施：根据行动计划开始实施改进措施。这可能涉及到培训员工、制定和实施新的过程、引入工具和技术等。
- 监控和评估改进效果：建立度量和监控机制，跟踪和评估改进措施的效果。收集和分析数据，进行内部审查和评估，以确保改进计划的有效性和进展。
- 持续改进：改进是一个持续的过程。根据监控和评估结果，对改进计划进行调整和优化，持续改进组织的过程和实践。
总之，制定一个CMMI改善计划需要明确目标、评估现状、选择改进领域、制定行动计划、建立改进团队、实施改进措施、监控和评估改进效果，并持续进行改进。这个过程需要组织内外的支持和参与，以确保改进计划的成功实施和目标的实现。
改善工具
在实施CMMI改进措施时，可以使用以下一些常见的工具和技术：
- 流程文档和模板：制定和更新流程文档和模板，以确保过程的一致性和标准化。这包括过程描述、工作指南、模板和表单等。
- 培训和教育：提供培训和教育，以确保团队成员对改进措施和新的过程有充分的理解和知识。培训可以包括CMMI的概念和要求，以及具体的工具和技术的使用方法。
- 会议和研讨会：组织会议和研讨会，让团队成员共同讨论和分享经验。这有助于促进团队合作和沟通，并推动改进措施的实施。
- 标准化工具和技术：使用标准化的工具和技术来支持和促进过程改进。例如，配置管理工具、需求管理工具、项目管理工具等，可以提高团队的效率和质量。
- 风险管理工具：使用风险管理工具来识别、评估和管理项目和过程中的风险。这有助于降低风险，提高项目和过程的可控性。
- 持续集成和自动化测试工具：使用持续集成和自动化测试工具来提高软件开发和测试的效率和质量。这包括构建工具、测试自动化工具、代码检查工具等。
- 数据分析工具：使用数据分析工具来收集、分析和可视化数据，以便进行过程监控和改进。这可以帮助团队识别问题和瓶颈，并做出基于数据的决策。
- 质量管理工具：使用质量管理工具来跟踪和管理质量相关的指标和度量。这包括缺陷跟踪工具、度量指标仪表板等。
这些工具和技术是支持CMMI改进计划实施的一些常见选择，具体使用哪些工具取决于组织的需求和情况。重要的是选择适合组织的工具，并确保团队成员对其使用方法和价值有充分的了解和培训。
一个实实在在的例子：
以下是CMMI中软件开发过程中的一个过程域（Process Area）的专用目标（Specific Goal）和具体的最佳实践（Specific Practice）的例子：
过程域：需求管理（Requirements Management） 专用目标：确保项目需求被有效地管理和控制。
具体的最佳实践：
- SP 1.1 确定需求：识别和文档化项目的需求，包括功能需求、性能需求、约束和限制等。
- SP 1.2 管理需求：建立并维护一个需求库，跟踪需求的状态、变更和关联关系。
- SP 1.3 识别需求的不一致性：识别和解决需求之间的冲突和不一致性，确保需求的一致性和完整性。
- SP 1.4 维护需求的一致性：在需求变更时，对相关的文档和工件进行及时更新，确保需求的一致性和可追溯性。
- SP 1.5 与利益相关者合作：与项目相关的利益相关者（如客户、用户、开发团队）合作，确保需求的准确理解和共识。
这些最佳实践旨在确保需求在软件开发过程中得到充分的管理和控制。通过识别、管理、解决冲突和保持一致性，可以提高需求的质量、满足用户期望，并减少开发过程中的变更和风险。
需要注意的是，这只是一个过程域的示例，CMMI中还有其他过程域，每个过程域都有自己的专用目标和最佳实践。具体的最佳实践会根据组织和项目的需求进行定制和实施。
本人能力有限，文中内容难免有纰漏，真诚欢迎大家斧正~
喜欢本文的朋友请三连哦！！！
另外本文也参考了网络上其他优秀博主的观点和实例，这里虽不能一一列举但内心属实感谢无私分享知识的每一位原创作者。