SWEBOK软件工程知识体系 - 8.软件工程过程

软件工程过程（SOFTWARE ENGINEERING PROCESS）

工程（engineering）过程由一组相互关联的活动组成，这些活动将一个或多个输入转换为输出，同时消耗资源来完成转换。传统工程学科的许多过程（如电气、机械、土木、化学）都涉及将能量和物理实体从一种形式转化为另一种形式，如将势能转化为电能的水电站大坝或利用化学过程将原油转化为汽油的炼油厂。

在这个知识领域（KA），软件工程过程与软件工程师为开发、维护和操作软件而完成的工作活动有关，例如需求、设计、构造、测试、配置管理和其他软件工程过程。为了可读性，“软件工程过程”在本文中将被称为“软件过程”。此外，请注意，“软件过程”表示工作活动，而不是已实施软件的执行过程。

指定软件过程有许多原因：促进人类理解、沟通和协调；帮助管理软件项目；以有效的方式度量和改进软件产品的质量；支持过程改进；以及为过程执行的自动化支持提供基础。

与软件工程过程KA密切相关的SWEBOK KAs包括软件工程管理、软件工程模型和方法以及软件质量；在工程基础KA中发现的度量和根本原因分析主题也密切相关。软件工程（Engineering）管理涉及为特定的软件项目裁剪、调整和实现软件过程（参见软件工程（Engineering）管理中的过程规划）。模型和方法支持软件开发和修改的系统方法。

软件质量KA涉及项目和产品质量的计划、保证和控制过程。工程基础中的测量和测量结果对于评估和控制软件过程是必不可少的。

1.软件过程定义

本主题涉及软件过程、软件过程管理和软件过程基础设施的定义。

如上所述，软件过程是将输入工作产品转换为输出工作产品的一组相互关联的活动和任务。软件过程的描述至少包括所需的输入、转换工作活动和生成的输出。如图8.2所示，软件过程还可以包括其进入和退出标准，并将工作活动分解为任务，这些任务是受管理责任约束的最小工作单元。过程输入可以是触发事件，也可以是另一个过程的输出。在流程开始之前，应满足进入标准。在一个过程成功结束之前，应满足所有规定的条件，包括输出工作产品或工作产品的验收标准。

软件过程可以包括子过程。例如，软件需求确认是用来确定需求是否能为软件开发提供充分的基础的过程；它是软件需求过程的一个子过程。需求验证的输入通常是软件需求规范和执行验证所需的资源（人员、验证工具、足够的时间）。需求验证活动的任务可能包括需求评审、原型设计和模型验证。这些任务涉及个人和团队的工作分配。需求确认的输出通常是一个经过验证的软件需求规范，它为软件设计和软件测试过程提供输入。软件需求过程的需求确认和其他子过程经常以各种方式交错和迭代；在软件开发或修改过程中，软件需求过程及其子过程可能多次进入和退出。

软件过程的完整定义还可以包括执行过程所需的角色和能力、IT支持、软件工程技术和工具、工作环境，以及用于确定执行过程的效率和有效性的方法和度量（关键性能指标）。
此外，软件过程可以包括交错的技术、协作和管理活动。

定义软件过程的符号包括用自然语言描述的组成活动和任务的文本列表、数据流图、状态图、BPMN、IDEF0、Petri网和UML活动图。一个过程中的转换任务可以定义为过程；一个过程可以被指定为一组有序的步骤，或者，作为执行任务中要完成的工作的清单。
必须强调的是，没有最佳的软件过程或一组软件过程。必须为每个项目和每个组织环境选择、调整和应用适当的软件过程。不存在理想的过程或过程集。

1.1. 软件过程管理

软件过程管理的两个目标是实现系统方法所产生的效率和有效性，以完成软件过程和生产工作产品，无论是在个人、项目或组织层面，并引入新的或改进的过程。

更改过程是为了期望新的或修改过的过程将提高过程的效率和/或有效性，以及由此产生的工作产品的质量。更改为新流程、改进现有流程、组织更改和基础结构更改（技术插入或工具更改）密切相关，因为所有这些更改通常都是以改进成本、开发进度或软件产品质量为目标启动的。过程变更不仅对软件产品有影响，而且常常导致组织变更。更改流程或引入新流程可能会在整个组织中产生连锁反应。例如，IT基础设施工具和技术的更改通常需要更改流程。

当首次部署其他新过程时，可能会修改现有过程（例如，在软件开发项目中引入检查活动可能会影响软件测试过程，请参阅软件质量KA和软件测试KA中的评审和审计）。这些情况也可以被称为“过程演化”。如果修改是广泛的，那么组织文化和商业模式的变化很可能是适应过程变化所必需的。

1.2. 软件过程基础设施

建立、实现和管理软件过程和软件生命周期模型通常发生在单个软件项目的层次上。然而，跨组织系统地应用软件过程和软件生命周期模型可以为组织内的所有软件工作带来好处，尽管这需要组织层面的承诺。软件过程基础设施可以提供过程定义、用于解释和应用过程的策略，以及用于实现过程的过程的描述。此外，软件过程基础设施可以提供资金、工具、培训以及被指派负责建立和维护软件过程基础设施的工作人员。

软件过程基础设施各不相同，这取决于组织的规模和复杂性以及组织内进行的项目。小型、简单的组织和项目需要小型、简单的基础设施。大型、复杂的组织和项目必然具有更大、更复杂的软件过程基础设施。在后一种情况下，可以建立各种组织单位（例如软件工程过程组或指导委员会）来监督软件过程的实施和改进。

一个常见的误解是，建立软件过程基础设施和实现可重复的软件过程将增加软件开发和维护的时间和成本。引入或改进软件过程是有成本的；然而，经验表明，通过提高效率、避免返工以及更可靠和更经济的软件，系统地改进软件过程往往会降低成本。因此，过程性能影响软件产品的质量。

2.软件生命周期

本主题讨论软件过程的类别、软件生命周期模型、软件过程适应和实际考虑。软件开发生命周期（SDLC）包括用于指定软件需求并将其转换为可交付软件产品的软件过程。软件产品生命周期（SPLC）包括软件开发生命周期和附加的软件过程，这些过程为软件产品的部署、维护、支持、演化、退役和所有其他接收退役过程提供了条件，包括软件配置管理和软件质量保证过程应用于整个软件产品生命周期的。一个软件产品生命周期可以包括用于进化和增强软件的多个软件开发生命周期。

单个软件过程之间没有时间顺序。软件过程之间的时间关系由软件生命周期模型提供：SDLC或SPLC。生命周期模型通常强调模型中的关键软件过程及其时间和逻辑上的相互依赖和关系。生命周期模型中软件过程的详细定义可以直接提供，也可以参考其他文档。

除了传达软件过程之间的时间和逻辑关系外，软件开发生命周期模型（或组织内使用的模型）还包括应用进入和退出标准的控制机制（例如，项目评审、客户批准、软件测试、质量阈值、演示、，团队共识）。一个软件过程的输出通常为其他过程提供输入（例如，软件需求为软件体系结构设计过程以及软件构建和软件测试过程提供输入）。多个软件过程活动的并发执行可能产生共享输出（例如，不同团队开发的多个软件组件之间的接口规范）。除非同时执行其他软件过程（例如，软件需求分析期间的软件测试规划可以改善软件需求），否则某些软件过程可能被认为效率较低。

2.1. 软件过程的分类

许多不同的软件过程被定义用于软件开发和软件维护生命周期的各个部分。这些过程可分类如下：

1. 主要过程包括软件开发、操作和维护的软件过程。
2. 支持过程在整个软件产品生命周期中间断或连续地应用，以支持主要过程；它们包括软件过程，如配置管理、质量保证、验证和确认。
3. 组织过程为软件工程提供支持；它们包括培训、过程度量分析、基础设施管理、组合和重用管理、组织过程改进和软件生命周期模型管理。
4. 跨项目过程，如重用、软件产品线和领域工程；它们涉及组织中不止一个软件项目。
   除了上面列出的软件过程之外，还包括以下过程。

项目管理过程包括计划和估计、资源管理、测量和控制、领导、管理风险、管理利益相关者以及协调软件开发和维护项目的主要、支持、组织和跨项目过程的过程。

软件过程也是为特定的需要而开发的，例如处理软件质量特征的过程活动（参见软件质量KA）。例如，软件开发过程中的安全问题可能需要一个或多个软件进程来保护开发环境的安全并降低恶意行为的风险。还可以开发软件过程，为建立对软件完整性的信心提供充分的依据。

2.2. 软件生命周期模型

软件的无形性和可塑性允许各种各样的软件开发生命周期模型，在线性模型中，软件开发的阶段是根据需要进行迭代，然后是集成、测试和交付单个产品；在迭代模型中，软件是以迭代周期中不断增加的功能为增量进行开发的；在敏捷模型中，通常需要向客户或用户代表频繁演示工作软件，这些客户或用户代表在短迭代周期中指导软件的开发，从而产生小的工作增量，可交付软件。如果需要，增量、迭代和敏捷模型可以将工作软件的早期子集交付到用户环境中。

线性SDLC模型有时被称为预测性软件开发生命周期模型，而迭代和敏捷SDLC被称为适应性软件开发生命周期模型。应注意的是，SPLC期间的各种维护活动可使用不同的SDLC模型进行，视维护活动而定。

各种软件开发生命周期模型的一个显著特征是管理软件需求的方式。线性开发模型通常在项目启动和规划期间尽可能地开发一套完整的软件需求。然后严格控制软件需求。变更控制委员会对软件需求的变更（请参阅“软件配置管理”中的“在变更控制委员会中请求、评估和批准软件变更”）。在每个增量中实现的软件需求的增量。软件需求可能会受到严格的控制，如在线性模型中，或者随着软件产品的发展，在修改软件需求时可能会有一些灵活性。敏捷模型最初可以定义产品范围和高级特性；然而，敏捷模型的设计是为了在项目期间促进软件需求的演化。

必须强调的是，SDLC从线性到敏捷的连续统一体并不是一条细细的直线。不同方法的元素可以合并到一个特定的模型中；例如，增量软件开发生命周期模型可以合并顺序软件需求和设计阶段，但是允许在软件构建期间修改软件需求和体系结构具有相当大的灵活性。

2.3. 软件过程适应

预定义的SDLC、SPLC和单个软件过程通常需要调整（或“定制”）以更好地满足本地需求。组织背景、技术创新、项目规模、产品关键性、监管要求、行业实践和企业文化可能决定所需的适应。个别软件过程和软件生命周期模型（开发和产品）的适应可能包括向软件过程、活动、任务和过程添加更多细节，以解决关键问题。它可能包括使用一组替代的活动来实现软件过程的目的和结果。适应还可以包括从开发或产品生命周期模型中省略明显不适用于要完成的工作范围的软件过程或活动。

2.4. 实际考虑

在实践中，软件过程和活动经常是交错、重叠和并发应用的。软件生命周期模型规定了离散的软件过程，具有严格规定的进入和退出标准以及规定的边界和接口，应被视为理想化，必须加以调整，以反映组织环境和业务环境中软件开发和维护的现实。

另一个实际考虑因素：软件过程（如配置管理、构造和测试）可以进行调整，以促进软件的操作、支持、维护、迁移和退役。

定义和裁剪软件生命周期模型时需要考虑的其他因素包括：对标准、指令和策略的符合性；客户需求；软件产品的关键性；以及组织成熟度和能力。其他因素包括工作性质（例如，对现有软件的修改与新开发）和应用领域（例如，航空航天与酒店管理）。

3.软件过程评估与改进

本主题讨论软件过程评估模型、软件过程评估方法、软件过程改进模型以及连续和分阶段的过程评级。软件过程评估用于评估软件过程的形式和内容，可以通过一组标准化的标准来指定。在某些情况下，使用术语“过程评估”和“能力评估”代替过程评估。能力评估通常由收单机构（或潜在收单机构）或代表收单机构（或潜在收单机构）的外部代理机构执行。结果被用作一个指标，表明供应商（或潜在供应商）使用的软件过程是否被收单机构接受。绩效评估通常在一个组织内进行，以识别需要改进的软件过程，或确定一个（或多个）过程是否满足给定过程能力或成熟度水平的标准。

过程评估是在整个组织、组织内的组织单位和单个项目的层次上进行的。评估可能涉及评估是否满足软件过程进入和退出标准，审查风险因素和风险管理，或确定经验教训等问题。过程评估采用评估模型和评估方法。该模型可以为组织内和组织间的项目基准比较提供一个规范。

过程审核不同于过程评估。执行评估以确定能力或成熟度的级别，并确定要改进的软件过程。审计通常是为了确定是否符合政策和标准。审计为管理层提供了对组织中正在执行的实际操作的可视性，以便就影响开发项目、维护活动或软件相关主题的问题做出准确而有意义的决策。

软件工程组织中的软件过程评估和改进的成功因素包括管理赞助、规划、培训、经验丰富且有能力的领导者、团队承诺、期望管理、变更代理的使用，以及试点项目和工具实验。其他因素包括评估员的独立性和评估的及时性。

3.1. 软件过程评估模型

软件过程评估模型通常包括被视为构成良好实践的软件过程的评估标准。这些实践可能只涉及软件开发过程，也可能包括诸如软件维护、软件项目管理、系统工程或人力资源管理等主题。

3.2. 软件过程评估方法

软件过程评估方法可以是定性的，也可以是定量的。定性评估依赖于专家的判断；定量评估基于对客观证据的分析为软件过程分配数字分数，这些客观证据表明已定义软件过程的目标和结果的实现。例如，与软件测试相比，软件检查过程的定量评估可以通过检查遵循的程序步骤和获得的结果加上有关发现的缺陷的数据以及发现和修复缺陷所需的时间来执行。

软件过程评估的典型方法包括计划、事实调查（通过问卷调查、访谈和工作实践观察收集证据）、过程数据的收集和验证以及分析和报告。过程评估可能依赖于评估人员的主观、定性判断，或者依赖于确定的工件、记录和其他证据的客观存在或不存在。

软件过程评估期间执行的活动以及评估活动的工作分配因软件过程评估的目的而异。软件过程评估可以用于开发用于提出过程改进建议的能力评级，或者可以用于获得过程成熟度评级，以便有资格获得合同或授予。

评估结果的质量取决于软件过程评估方法、获得数据的完整性和质量、评估团队的能力和客观性以及评估过程中审查的证据。软件过程评估的目标是获得洞察，从而确定一个或多个过程的当前状态，并为过程改进提供基础；通过遵循一致性检查表执行软件过程评估而没有获得洞察，增加的价值不大。

3.3. 软件过程改进模型

软件过程改进模型强调不断改进的迭代循环。软件过程改进周期通常涉及测量、分析和更改的子过程。Plan-Do-Check-Act模型是一种众所周知的软件过程改进迭代方法。改进活动包括确定所需改进并确定其优先级（规划）；引入改进，包括变更管理和培训（实施）；与以前的或示范性的过程结果和成本相比评估改进（检查）；以及进一步修改（实施）。例如，可以应用Plan-Do-Check-Act过程改进模型来改进增强缺陷预防的软件过程。

3.4. 连续和分阶段的软件过程评级

软件过程能力和软件过程成熟度通常采用五个或六个级别来评定，以表征组织内使用的软件过程的能力或成熟度。

连续评级系统包括为每个感兴趣的软件过程分配一个评级；分阶段评级系统是通过将相同的成熟度评级分配给指定过程级别内的所有软件过程而建立的。表8.1给出了连续和分阶段过程水平的表示。连续模型通常使用0级评级；分阶段模型通常不使用。

在表8.1中，级别0表示软件过程未完全执行或可能未执行。在1级，软件过程正在执行（能力评级），或者成熟度1级组中的软件过程正在执行，但是临时的、非正式的。在2级，软件过程（能力评级）或成熟度2级过程的执行方式为管理层提供对中间工作产品的可视性，并可以对过程之间的转换施加某种控制。在第3级，单个软件过程或成熟度级别3组中的过程加上成熟度级别2中的一个或多个过程被很好地定义（可能在组织策略和过程中），并在不同的项目中重复。过程能力或成熟度的3级为整个组织的过程改进提供了基础，因为过程是以类似的方式进行的。这允许跨多个项目以统一的方式收集性能数据。在成熟度级别4，可以应用定量度量并用于过程评估；可以使用统计分析。在成熟度级别5，应用了持续过程改进的机制。

连续和分阶段表示可以用来确定软件过程改进的顺序。在连续表示中，不同软件过程的不同能力水平为确定软件过程改进的顺序提供了指导。在阶段性表示中，满足成熟度级别上的一组软件过程的目标是为成熟度级别完成的，这为改进下一个更高级别的所有软件过程提供了基础。

4.软件测量

本主题讨论软件过程和产品度量、度量结果的质量、软件信息模型和软件过程度量技术（参见工程基础KA中的度量）。

在实施新过程或修改当前过程之前，应获得当前情况的测量结果，为当前情况和新情况之间的比较提供基线。例如，在引入软件检查过程之前，应该测量修复测试发现的缺陷所需的工作。在引入检验过程后的初始启动期之后，检验加测试的综合工作量可以与之前单独测试所需的工作量进行比较。如果流程发生变化，也会有类似的考虑。

4.1. 软件过程与产品度量

软件过程和产品度量与确定软件过程、活动或任务的效率和有效性有关。软件过程、活动或任务的效率是实际消耗的资源与在完成软件过程、活动或任务时预期或期望消耗的资源的比率（参见软件工程经济学中的效率）。工作量（或等效成本）是大多数软件过程、活动和任务的主要资源度量；它以工时、人日、员工周或员工月工作量等单位或欧元或美元等等效货币单位度量。

有效性是软件过程、活动或任务产生的实际输出与预期输出的比率；例如，在软件测试期间检测和纠正的实际缺陷数量与可能基于类似项目的历史数据检测和纠正的预期缺陷数量（见软件中的有效性）工程经济学。请注意，软件过程有效性的度量要求度量相关的产品属性；例如，度量在软件测试期间发现和纠正的软件缺陷。

在测量产品属性以确定过程有效性时必须小心。例如，通过测试检测和纠正的缺陷数量可能无法达到预期的缺陷数量，因此提供了误导性的低有效性度量，或者是因为被测试的软件比通常的质量更好，或者是因为引入了一个新引入的上游检查过程减少了软件中剩余的缺陷数量。

在确定软件过程有效性时可能很重要的产品度量包括产品复杂性、总缺陷、缺陷密度、需求质量、设计文档和其他相关工作产品。

还要注意，效率和有效性是独立的概念。一个有效的软件过程在实现期望的软件过程结果时可能是低效的；例如，与预期相比，花费在发现和修复软件缺陷上的工作量可能非常大，并导致低效率。

一个有效的过程在完成输入工作产品到输出工作产品的期望转换时可能是无效的；例如，在测试过程中没有发现并纠正足够数量的软件缺陷。

软件过程、活动或任务执行方式的低效和/或低效的原因可能包括以下一个或多个问题：输入工作产品不足、人员缺乏经验、缺乏足够的工具和基础设施、学习新过程、复杂产品或不熟悉的产品域。软件过程执行的效率和有效性也受到诸如软件人员流动、进度变化、新的客户代表或新的组织政策等因素的影响（无论是积极的还是消极的）。

在软件工程中，执行一个过程、活动或任务的生产率是所产生的产出除以所消耗的资源的比率；例如，发现和纠正的软件缺陷的数量除以所付出的工时（见软件工程经济学中的生产率）。生产力的准确度量必须包括用于满足软件过程、活动或任务的退出标准的全部工作；例如，在软件开发生产力中必须包括纠正在软件测试期间发现的缺陷所需的工作。

生产力的计算必须考虑到工作完成的环境。例如，如果团队成员纠正他们在软件开发人员的单元测试或跨职能敏捷团队中发现的缺陷，那么纠正发现的缺陷的努力将包括在软件团队的生产率计算中。或者生产率计算可能包括软件开发人员的工作或独立测试团队的工作，这取决于谁修复了独立测试人员发现的缺陷。注意，这个例子指的是开发人员团队或测试人员团队的工作，而不是个人。由于影响软件工程师个人生产力的因素很多，在个人水平上计算的软件生产力可能会产生误导。

软件过程和工作产品度量的标准化定义和计数规则对于在组织内跨项目提供标准化度量结果、填充可分析的历史数据存储库以确定需要改进的软件过程是必要的，建立基于累积数据的预测模型。在上面的例子中，软件缺陷的定义和测试工作的工作时间加上缺陷和工作的计数规则对于获得满意的测量结果是必要的。

软件过程制度化的程度很重要；未能制度化软件过程可以解释为什么“好”的软件过程并不总是产生预期的结果。软件过程可以通过在本地组织单元内或跨企业的较大单元采用而制度化。

4.2. 测量结果的质量

过程和产品测量结果的质量主要取决于测量结果的可靠性和有效性。不满足这些质量标准的度量可能导致错误的解释和错误的软件过程改进计划。软件度量的其他理想特性包括易于收集、分析和表示，以及因果之间的强相关性。
软件工程管理KA中的软件工程度量主题描述了实现软件度量程序的过程。

4.3. 软件信息模型

软件信息模型允许对软件过程和软件产品属性进行建模、分析和预测，为相关问题提供答案，实现过程和产品改进目标。所需的数据可以收集并保存在存储库中；可以分析数据并构建模型。在软件项目期间和项目完成后，对软件信息模型进行验证和细化，以确保足够的准确度，并了解和理解其局限性。软件信息模型也可以为软件项目以外的上下文开发；例如，软件信息模型可以为应用于整个组织的过程开发，例如组织级的软件配置管理或软件质量保证过程。

分析驱动的软件信息模型构建包括开发、校准、将输入变量转换为期望输出的假设；例如，产品的大小和复杂程度可以转化为开发软件产品所需的估计工作量，使用从过去项目的观察数据中得到的回归方程。通过调整模型中的参数来校准模型，以匹配过去项目的观测结果；例如，非线性回归模型中的指数可以通过将回归方程应用于不同的过去项目集（而不是用于开发模型的项目）来改变。

一个模型是通过比较不同的相似数据集的计算结果和实际结果来评估的。有三种可能的评估结果：

1. 为不同数据集计算的结果与该数据集的实际结果相差很大，在这种情况下，导出的模型不适用于新的数据集，不应用于分析或预测未来的项目；
2. 为新数据集计算的结果与该数据集的实际结果接近，在这种情况下，对模型的参数进行微小调整以提高一致性；
3. 新数据集和后续数据集的计算结果非常接近，无需对模型进行调整。

对模型的持续评估可能表明，随着模型应用环境的变化，需要随着时间的推移进行调整。

目标/问题/度量（Goals/Questions/Metrics，GQM）方法最初用于建立度量活动，但也可以用于指导软件过程的分析和改进。
它可以用来指导分析驱动的软件信息模型的建立；从软件信息模型得到的结果可以用来指导过程改进。
以下示例说明了GQM方法的应用：

• 目标：在六个月内将平均变更请求处理时间减少10%。
• 问题1-1：基线变更请求处理时间是多少？
• 指标1-1-1：开始日期变更请求处理时间的平均值
• 指标1-1-2：开始日期变更请求处理时间的标准偏差
• 问题1-2：当前变更请求处理时间是多少？
• 指标1-2-1：当前变更请求处理时间的平均值
• 指标1-2-2：变更请求处理时间的标准偏差

4.4. 软件过程度量技术

软件过程度量技术用于收集过程数据和工作产品数据，将这些数据转换为有用的信息，并对这些信息进行分析，以确定需要改进的过程活动。在某些情况下，可能需要新的软件过程。
过程度量技术还提供了度量过程改进计划效果所需的信息。过程测量技术可用于收集定量和定性数据。

4.4.1. 定量过程测量技术

定量过程测量技术的目的是收集、转换和分析定量过程和工作产品数据，这些数据可用于指示哪里需要过程改进，以及评估过程改进计划的结果。定量过程测量技术是用来收集和分析数据的数字形式，数学和统计技术可以应用。

定量过程数据可以作为软件过程的副产品来收集。例如，软件测试中发现的缺陷数量和花费的工时可以通过直接测量来收集，缺陷发现的生产率可以通过计算每个工时发现的缺陷得到。

质量控制的基本工具可用于分析定量过程测量数据（例如，检查表、帕累托图、直方图、散点图、运行图、控制图和因果图）（见工程基础KA中的根本原因分析）。此外，可以使用各种统计技术，从中位数和平均数的计算到多元分析方法（见工程基础KA中的统计分析）。

使用定量过程测量技术收集的数据也可以用作仿真模型的输入（参见工程基础KA中的建模、原型和仿真）；这些模型可以用来评估各种方法对软件过程改进的影响。

正交缺陷分类（ODC）可用于定量过程测量数据的分析。ODC可用于将检测到的缺陷分类，并将每个类别中的缺陷与一组缺陷产生的软件过程或软件过程联系起来（参见软件质量KA中的缺陷描述）。例如，软件接口缺陷可能源于不充分的软件设计过程；改进软件设计过程将减少软件接口缺陷的数量。ODC可以为应用根本原因分析提供定量数据。

统计过程控制可以用来跟踪过程的稳定性，或缺乏过程的稳定性，使用控制图。

4.4.2. 定性过程测量技术

定性过程测量技术包括访谈、问卷调查和专家判断可用于增强定量过程测量技术。群体共识技术，包括德尔菲技术，可以用来获得利益相关者群体之间的共识。

5.软件工程过程工具

软件过程工具支持许多用于定义、实现和管理单个软件过程和软件生命周期模型的符号。它们包括数据流图、状态图、BPMN、IDEF0图、Petri网和UML活动图等符号的编辑器。在某些情况下，软件过程工具允许不同类型的分析和模拟（例如，离散事件模拟）。此外，通用业务工具（如电子表格）也可能有用。

计算机辅助软件工程（CASE）工具可以加强集成过程的使用，支持过程定义的执行，并为人类执行定义良好的过程提供指导。简单的工具，如文字处理器和电子表格，可用于准备过程、活动和任务的文本描述；这些工具还支持多个软件过程（如干系人需求分析、软件需求规范、软件体系结构，以及软件过程的结果，如文档、软件组件、测试用例和问题报告。

本指南中的大部分知识领域描述了可用于管理该KA中的流程的专用工具。具体而言，请参阅软件配置管理KA，以了解可用于管理软件产品的构建、集成和发布过程的软件配置管理工具的讨论。其他工具，如用于需求管理和测试的工具，在适当的KAs中进行了描述。

软件过程工具可以支持涉及地理上分散（虚拟）团队的项目。越来越多的软件过程工具通过云计算设施以及专用基础设施提供。

项目控制面板或仪表板可以显示软件项目的选定过程和产品属性，并指示在控制范围内的度量和需要纠正措施的度量。