使用过程评估模型来确定过程能力的概念是基于一个二维框架。第一个维度是由过程参考模型（过程维度）定义的过程来提供。第二个维度是由进一步细分到过程属性的能力等级（能力维度）所构成。过程属性提供了过程能力可度量的特性。
过程评估模型从过程参考模型中选择过程并增补了指标。这些指标支持收集客观证据，使评估师能 够根据能力维度对过程进行评定分配。
关系如图1所示：
图1—过程评估模型关系
过程是根据它们所处理的活动领域来划分成不同的过程组。
这些过程组被组织成三个过程类别：主要生命周期过程、组织生命周期过程和支持生命周期过程。
对于每个过程，都会制定一个目的声明，其中包含在特定环境中执行该过程时所要实现的独特功能目标。每个目的声明都关联了一系列具体的结果，作为过程执行后预期正面成效的清单。
在过程维度方面，Automotive SPICE过程参考模型提供了如图2所示的一系列过程集合。
图2—Automotive SPICE过程参考模型–概览
主要生命周期过程类别包含可能适用于从供应商处采购产品的过程，或在响应利益相关方需求并提供产品（包括规范、设计、实施、集成和验证所需的工程过程）时进行产品开发的过程。
主要生命周期过程类别包含以下过程组：
l采购过程组
l供应过程组
l系统工程过程组
l确认过程组
l软件工程过程组
l机器学习工程过程组
l硬件工程过程组
采购过程组（ACQ）包含一个由客户执行的过程，或由供应商在其作为自身供应商的客户角色时执行的过程，目的是采购产品或服务。
ACQ.4 供应商监控
表3—主要生命周期过程-ACQ过程组
供应过程组（SPL）包含一个由供应商执行的过程，目的是提供产品或服务。
SPL.2 产品发布
表4—主要生命周期过程-SPL过程组
系统工程过程组（SYS）包含处理客户和内部需求的挖掘和管理、系统架构的定义以及系统级别的集成和验证的过程。
SYS.1 需求挖掘
SYS.2 系统需求分析
SYS.3 系统架构设计
SYS.4 系统集成与集成验证
SYS.5 系统验证
表5—主要生命周期过程-SYS过程组
确认过程组（VAL）包含一个执行的过程，目的是提供证据，表明待交付的产品满足其预期用途的期望。
VAL.1 验证
表6—主要生命周期过程-VAL过程组
软件工程过程组（SWE）包含处理从系统需求派生的软件需求的管理、相应软件架构和设计的开发以及软件的实现、集成和验证的过程。
SWE.1 软件需求分析
SWE.2 软件架构设计
SWE.3 软件详细设计与单元构建
SWE.4 软件单元验证
SWE.5 软件组件验证与集成验证
SWE.6 软件验证
表7—主要生命周期过程-SWE过程组
机器学习工程过程组（MLE）包含处理从软件需求派生的机器学习需求的管理、相应机器学习架构的开发、机器学习模型的训练以及根据机器学习需求对机器学习模型进行测试的过程。
MLE.1 机器学习需求分析
MLE.2 机器学习架构
MLE.3 机器学习训练
MLE.4 机器学习模型测试
表8—主要生命周期过程-MLE过程组
硬件工程过程组（HWE）包含处理从系统需求派生的硬件需求的管理、相应硬件架构和设计的开发以及硬件验证的过程。
HWE.1 硬件需求分析
HWE.2 硬件设计
HWE.3 硬件设计验证
HWE.4 硬件需求验证
表9—主要生命周期过程-HWE过程组
支持生命周期过程类别包含可能在生命周期的不同阶段被其他任何过程采用的过程。
SUP.1 质量保证
SUP.8 配置管理
SUP.9 问题解决管理
SUP.10 变更请求管理
SUP.11 机器学习数据管理
表10—支持生命周期过程-SUP过程组
组织生命周期过程类别包含开发过程、产品和资源资产的过程，这些资产在组织内的项目中使用时，可能有助于组织实现其业务目标。
组织生命周期过程类别包含以下过程组：
l管理过程组（MAN）；
l过程改进过程组（PIM）；
l重用过程组（REU）。
管理过程组（MAN）包含可由任何在生命周期内管理任何类型项目或过程的人员使用的过程。
MAN.3 项目管理
MAN.5 风险管理
MAN.6 度量
表11—组织生命周期过程-MAN过程组
过程改进过程组（PIM）包含一个过程，其中包含改进组织单位内执行的过程的实践。
PIM.3 过程改进
表12—组织生命周期过程-PIM过程组
重用过程组（REU）包含一个过程，旨在系统地利用组织产品组合中的重用机会。
REU.2 重用产品的管理
表13—组织生命周期过程-REU过程组
度量框架为能力维度提供了必要的要求和规则。它定义了一个模式，使评估者能够确定给定过程的能力等级。这些能力等级被定义为度量框架的一部分。
为了进行评定，度量框架提供了过程属性，这些属性定义了过程能力的可度量特性。每个过程属性都被分配到一个特定的能力级别。某一过程属性的实现程度通过基于定义好的评定量表的评定来表示。评估者可以从一个过程能力等级模型中推导出给定过程的最终能力等级。
Automotive SPICE定义了自己的度量框架。
|注：Automotive SPICE度量框架是ISO/IEC 33020:2019的改编版。本章中从ISO/IEC 33020引入的文本用斜体字书写，并用左侧边栏竖线标记。
过程能力等级和相关的过程属性在第5章中有详细描述。
过程属性是过程的特征，可以根据实现程度进行评估，从而度量过程的能力。它们适用于所有过程。
一个能力等级的特点是一个或多个过程属性的实现，这些属性的实现能显著提高执行过程的能力。每个属性都针对能力等级的特定方面。这些等级构成了一种通过提高任何过程的能力来逐步进步的合理方式。
表14列出了六个能力等级，包含九个过程属性：
等级0：不完整的过程 | 该过程未实施或未能实现其过程目的。 |
等级1：已执行的过程 | 已实施的过程实现了其过程目的。 |
等级2：已管理的过程 | 之前描述的已执行的过程现在以管理的方式（计划、监控和调整）实施，并且其工作产品得到适当的建立、控制和维护。 |
等级3：已建立的过程 | 之前描述的已管理的过程现在使用已定义的过程来实现其过程成果。 |
等级4：可预测的过程 | 之前描述的已建立的过程现在在定义的范围内以可预测的方式运行，以实现其过程成果。确定了量化管理需求，收集并分析度量数据以识别可分配的变异原因。采取纠正措施以解决可分配的变异原因。 |
等级5：创新的过程 | 之前描述的可预测的过程现在不断得到改进，以响应组织变化。 |
表14—过程能力等级
在这个过程评估模型中，能力的确定是基于表15“过程属性”中列出的九个过程属性（PA）来进行的。
属性编号 | 过程属性 |
等级0：不完整的过程 | |
等级1：已执行的过程 | |
PA 1.1 | 过程实施过程属性 |
等级2：已管理的过程 | |
PA 2.1 | 实施管理过程属性 |
PA 2.2 | 工作产品管理过程属性 |
等级3：已建立的过程 | |
PA 3.1 | 过程定义过程属性 |
PA 3.2 | 过程部署过程属性 |
等级4：可预测的过程 | |
PA 4.1 | 定量分析过程属性 |
PA 4.2 | 定量控制过程属性 |
等级5：创新的过程 | |
PA 5.1 | 过程创新过程属性 |
PA 5.2 | 过程创新实施过程属性 |
表15—过程属性
为了支持过程属性的评定，度量框架提供了一个定义好的评定量表，该量表具有细化的选项、不同的评定方法和不同的聚合方法，具体取决于评估的类别（例如，组织成熟度评估所需）。
|在此过程度量框架中，过程属性是可度量的过程能力特性。过程属性评定是对被评|估过程的过程属性实现程度的判断。
评定量表如表16所示。
注意：评定量表与ISO/IEC 33020:2019相同。
N | 未实现 | 在被评估的过程中，几乎没有或根本没有证据表明已实现了定义的过程属性。 |
P | 部分实现 | 在被评估的过程中，有证据表明已接近并部分实现了定义的过程属性。过程属性的某些实现方面可能是不可预测的。 |
L | 大部分实现 | 在被评估的过程中，有证据表明已系统地接近并显著实现了定义的过程属性。在被评估的过程中，可能存在与此过程属性相关的一些弱点。 |
F | 完全实现 | 在被评估的过程中，有证据表明已完全并系统地实现了定义的过程属性。在被评估的过程中，不存在与此过程属性相关的显著弱点。 |
表16—评定量表
|上述顺序量表应根据过程属性的实现百分比来理解。相应的百分比应为：
N | 未实现 | 0到≤15%的实现程度 |
P | 部分实现 | >15%到≤50%的实现程度 |
L | 大部分实现 | >50%到≤85%的实现程度 |
F | 完全实现 | >85%到≤100%的实现程度 |
表17—评定量表百分比值
|顺序量表可以按照以下定义进一步细化P和L的度量。
P- | 部分实现 | 在被评估的过程中，有证据表明已接近并部分实现了定义的过程属性。过程属性的许多实现方面可能是不可预测的。 |
P+ | 部分实现 | 15%到≤50%的实现程度在被评估的过程中，有证据表明已接近并部分实现了定义的过程属性。过程属性的某些实现方面可能是不可预测的。 |
L- | 大部分实现 | 在被评估的过程中，有证据表明已系统地接近并显著实现了定义的过程属性。在被评估的过程中，可能存在与此过程属性相关的许多弱点。 |
L+ | 大部分实现 | 在被评估的过程中，有证据表明已系统地接近并显著实现了定义的过程属性。在被评估的过程中，可能存在与此过程属性相关的一些弱点。 |
表18—评定量表的细化
相应的百分比应为：
P- | 部分实现 | >15%到≤32.5%的实现程度 |
P+ | 部分实现 | >32.5%到≤50%的实现程度 |
L- | 大部分实现 | >50%到≤67.5%的实现程度 |
L+ | 大部分实现 | >67.5%到≤85%的实现程度 |
表19—细化后的评定量表百分比值
评定与聚合方法取自ISO/IEC 33020:2019，其中提供了以下定义：
|过程成果是成功实现过程目的的可观察结果。
|过程属性结果是实现特定过程属性的可观察结果。
|过程成果和过程属性结果可以被描述为提供过程属性评定的中间步骤。
|在进行评定时，所采用的评定方法应与评估类别相关。以下评定方法被定义。
|评定方法的使用可以根据评估的类别、范围和上下文而有所不同。主评估师应决定使用哪种（如果有的话）评定方法。所选的评定方法应在评估输入中指定，并在评估报告中引用。
ISO/IEC 33020:2019提供了以下3种评定方法：
ISO/IEC 33020:2019提供了以下示例：
|在进行评估时，评定可以跨一个或两个维度进行总结。
|例如，当评估：
l给定过程的过程属性时，可以聚合相关过程（属性）结果的评定 - 这样的聚合将作为垂直聚合（一个维度）执行。
l给定过程属性在多个过程实例上的过程（属性）结果时，可以聚合给定过程（属性）结果的相关过程实例的评定 - 这样的聚合将作为水平聚合（一个维度）执行。
l给定过程的过程属性时，可以聚合所有过程实例的所有过程（属性）结果的评定 - 这样的聚合将在整个评定范围内作为矩阵聚合（两个维度）执行。
该标准定义了不同的聚合方法。更多信息可以从ISO/IEC 33020:2019中获取。
根据表20“能力等级”中定义的过程能力等级模型，某一过程所达到的过程能力等级应由该过程的过程属性评定得出。
过程能力等级模型定义了每个级别的达成如何取决于被评估级别和所有较低级别的过程属性的评定的规则。
通常，要达到给定的级别，需要大部分或完全达到相应的过程属性，并完全达到任何更低级别的过程属性。
等级 | 过程属性 | 评定 |
等级1 | PA 1.1：过程实施过程属性 | 大部分或完全 |
等级2 | PA 1.1：过程实施过程属性 PA 2.1：过程实施管理过程属性 PA 2.2：工作产品管理过程属性 | 完全 大部分或完全 大部分或完全 |
等级3 | PA 1.1：过程实施过程属性 PA 2.1：过程实施管理过程属性 PA 2.2：工作产品管理过程属性 PA 3.1：过程定义过程属性 PA 3.2：过程部署过程属性 | 完全 完全 完全 大部分或完全 大部分或完全 |
等级4 | PA 1.1：过程实施过程属性 PA 2.1：过程实施管理过程属性 PA 2.2：工作产品管理过程属性 PA 3.1：过程定义过程属性 PA 3.2：过程部署过程属性 PA 4.1：定量分析过程属性 PA 4.2：定量控制过程属性 | 完全 完全 完全 完全 完全 大部分或完全 大部分或完全 |
等级5 | PA 1.1：过程实施过程属性 PA 2.1：过程实施管理过程属性 PA 2.2：工作产品管理过程属性 PA 3.1：过程定义过程属性 PA 3.2：过程部署过程属性 PA 4.1：定量分析过程属性 PA 4.2：定量控制过程属性 PA 5.1：过程创新过程属性 PA 5.2：过程创新实施过程属性 | 完全 完全 完全 完全 完全 完全 完全 大部分或完全 大部分或完全 |
表20—能力级别和相应的过程属性评定
过程评估模型提供了一系列指标，用于确定在项目和组织单位的实例化过程中是否存在过程成果和过程属性结果（成就）。这些指标为评估人员提供了收集必要客观证据的指导，以支持对能力的判断。它们并不打算被视为必须遵循的一组检查清单。
根据ISO/IEC 33004标准，过程评估模型需要定义一组评估指标：
|评估指标
|过程评估模型应基于一组评估指标，这些指标应：
|a) 明确阐述所选过程参考模型中定义的每个过程的目的和过程成果，这些过程在过程评估模型的范围内；
|b) 展示过程评估模型范围内过程属性的实现情况；
|c) 展示过程评估模型范围内过程质量水平的实现情况（如相关）。
|评估指标通常分为三类：
|a) 支持实现过程目的或特定过程属性的实践；
|b) 展示各自成就的信息项及其特征；
|c) 支持各自成就的资源和基础设施。
|[ISO/IEC 33004:2015, 6.3.1]
在此评估模型中，仅使用实践和信息项。
实践代表活动导向的指标，而信息项代表结果导向的指标。实践和信息项都用于判断在评估过程中要收集和积累的客观证据。
作为第一类评估指标，提供了实践，这些实践可以分为两种类型：
1.基本实践（BP），适用于能力等级1
它们提供了过程成果实现程度的指示。基本实践与一个或多个过程成果相关，因此总是针对特定过程而非通用过程。
2.通用实践（GP），适用于能力等级1至5
它们提供了过程属性实现程度的指示。通用实践与一个或多个过程属性的成就相关，因此适用于任何过程。
作为第二类评估指标，信息项（II）及其特征（IIC）在附录B中提供。
这些旨在为评估人员提供良好实践和最新知识指南。因此，信息项及其特征应该是评估期间可快速访问的信息源。
信息项的特征不应解释为相应工作产品的必需结构，这是由项目和组织分别定义的。
请参阅第3.3.2章，了解信息项和工作产品之间的区别。
ISO 33004:2015要求将评估指标映射到过程属性，如图3所示。
等级1的过程能力仅通过度量过程成果的实现程度来表征。根据ISO 33003:2015，度量框架要求每个等级揭示一个过程属性。因此，针对能力等级1的唯一过程实施属性（PA.1.1）具有单一的通用实践（GP 1.1.1），作为编辑参考指向相应的过程实施指标（见图3和第4章）。
图3—评估指标与过程能力之间的关系
基本实践/指标和通用实践/指标与过程成果和成就之间的详细映射分别在第4章和第5章的相应表格中提供。
为了判断过程成果和过程属性成就的存在与否，评估需要获得客观证据。所有这些证据要么来自对所评估过程的特定输出的工作产品的检查，要么来自过程执行者和管理者的陈述。这些证据的来源要么是被评估过程的存储库内容，要么是被评估过程的执行者和管理者提供的证词。
如3.3.1章所述，该过程评估模型提供了信息项，作为评估者在判断过程属性成就时的指标。
ISO/IEC 33001对“信息项”一词提供了以下定义：
|信息项
|为供人类使用而生产、存储和交付的可单独识别的信息体
|注1：在系统、软件或服务的生命周期中，可以产生信息项的多个版本。同义词：信息产品。
|[ISO/IEC 33001:2015, 3.1.4]
注：人类使用包括工具存储、管理和处理的信息。
“工作产品”一词的一个常见定义是：
|工作产品
|执行过程产生的成果或产物
|[ISO/IEC/IEEE 24765:2017]
这两个术语在评估中的使用上下文不同：
l信息项定义了评估者用来判断过程属性成就的相关信息片段。
l工作产品是被评估的组织在执行、管理、建立、分析和创新过程时产生的。
信息项（及其特征）为在检查被评估组织中可用的工作产品时“要寻找什么”提供了指导。在相关工作产品中实施信息项的程度（符合其定义的特征）作为支持特定过程评估的客观证据。需要有文件化的过程和评估者的判断，以确保在使用这些信息时考虑到过程上下文（应用领域、业务目的、开发方法、组织规模等）。
因此，不应将信息项误认为是被评估组织自身生成的工作产品。信息项与评估者在评估过程成果和过程属性成就时作为样本证据的工作产品之间没有一对一的关系。一个过程产生的输出可能包含多个信息项特征，而多个输出也可能包含相同的信息项特征。
在考虑给定上下文的情况下，工作产品是否有助于实现过程的预期目的时，应将信息项特征视为指标。上下文敏感性意味着评估者的判断需要确保在使用信息项时考虑到实际上下文（应用领域、业务目的、开发方法、组织规模等）。
在评估过程属性时，作为证据的工作产品不一定是被评估过程的输出，也可以来自组织的其他过程。一旦这样的工作产品在被评估的过程执行中被使用，评估者就可以将其视为客观证据。
在很多情况下，工作产品包含文档方面，如规范、报告、记录、架构设计、软件代码等。
不包含任何文档方面内容的工作产品示例有软件二进制文件、原始数据或物理电子硬件。
“过程”一词可以在三个抽象层次上理解。请注意，这些抽象层次并不是要定义一个严格的非黑即白的划分，也不是要提供一个科学的分类模式——这里的要点是要理解，在实践中，当涉及到“过程”一词时，存在不同的抽象层次，而PAM位于最高层次。
图4—“过程”一词可能的抽象层次
为了与他人分享在产品开发过程中获得的经验（即在DOING层面），需要创建一个HOW层面。然而，HOW总是特定于某一特定环境，如公司、组织单位或产品线。例如，项目、组织单位或公司A的HOW可能不适用于项目、组织单位或公司B。然而，两者都可能需要遵守PAM指标所代表的原则，以实现过程成果和过程属性成就。这些指标位于WHAT层面，而决定具体模板、程序和工具等的解决方案则留给HOW层面。
生命周期模型以逻辑上的时间顺序定义阶段和活动，可能包括循环或并行化。例如，一些标准，如ISO 26262或ISO/SAE 21434，都围绕生命周期模型展开（实际上，这些标准都不代表ISO/IEC 33004中的PRM）。公司、组织单位或项目将解释标准中给出的这种通用生命周期模型，然后将其细化为角色、组织交互和接口、工具或工具链、工作指令和工件。因此，生命周期模型是HOW层面的概念（见3.3.3节）。
相比之下，根据ISO/IEC 33004（以前为ISO/IEC 15504-2）的PRM/PAM通过从任何HOW层面抽象出来，位于WHAT层面，见3.3.3节的图4。在Automotive SPICE®中，这一点一直并且现在仍然由过程MAN.3项目管理在BP2“定义项目生命周期”中要求。PRM/PAM将一组连贯且相关的特定技术主题特性组合在一起，并将其称为“过程”。换句话说，PRM中的过程代表一个“独特的概念仓”。在这方面，PRM/PAM：
l既不预定义，也不阻止按照任何顺序执行PRM过程或基本实践。最终，在Automotive SPICE中，必须满足一致性，这是MAN.3或SYS.x、SWE.x和HWE.x中可追溯性/一致性基本实践所要求的；
l不预定义任何特定的工作产品结构或工作产品蓝图。例如，过程SYS.2并不意味着必须有一份包含利益相关方提供的所有内容的系统需求规格说明书。
因此，评估者的责任是将这样一个HOW层面的元素映射到PAM中的评估指标，见图5。
图5—执行过程评估以确定过程能力
在这方面，PRM或PAM也不应该代表产品元素层次结构。
过程维度中的具体过程可参照汽车Automtive SPICE过程参考模型来确定，该模型在下表中以左侧的红色条标注。与过程维度中每一具体过程相关的表格均包含过程参考模型以及用于定义过程评估模型的过程实施指标。这些过程实施指标包括基本实践和输出信息项。
过程参考模型 | 过程ID 过程名称 过程目的 过程成果 | 各个过程都通过唯一的过程ID和过程名称进行标识。提供了过程目的说明，并定义了过程成果，以表示Automotive SPICE过程参考模型的过程维度。 |
过程实施指标 | 基本实践 | 为过程提供了一套基本实践，定义了为完成过程目的和实现过程成果而要执行的活动。 基本实践的标题在过程末尾进行了总结，以展示它们与过程成果的关系。 |
输出信息项 | 与完成过程目的和实现过程成果相关的输出信息项在过程末尾进行了总结，以展示它们与过程成果的关系。 注：有关每个信息项的特性，请参阅附录B。 |
表21—过程描述的模板
过程ID | ||||
ACQ.4 | ||||
过程名称 | ||||
供应商监控 | ||||
过程目的 | ||||
本过程的目的是跟踪和评估外部合同供应商公司相对于商定承诺的绩效。 | ||||
过程成果 | ||||
1) 执行客户和供应商之间商定的联合活动。 2) 所有商定交换的信息在客户和供应商之间定期沟通。 3) 根据协议监控供应商的表现。 4) 如需更改协议，客户和供应商之间进行协商并在协议中记录。 | ||||
基本实践 | ||||
ACQ.4.BP1：商定并维护联合活动、联合接口和要交换的信息。建立和维护关于要交换的信息、联合活动、联合接口、职责、联合活动的类型和频率、沟通、会议、状态报告和评审的协议。 | ||||
ACQ.4.BP2：交换所有商定的信息。使用客户和供应商之间定义的联合接口来交换所有商定的信息。 | ||||
ACQ.4.BP3：与供应商一起评审开发工作产品。在商定的定期基础上与供应商一起评审开发工作产品，涵盖技术方面、问题和风险。跟踪未完成的措施。 注1：参见SUP.9以了解问题的管理 | ||||
ACQ.4.BP4：评审供应商的进度。在商定的定期基础上评审供应商在进度、质量和成本方面的进度。跟踪未完成的措施直至关闭，并执行风险缓解活动。 注2：参见MAN.5以了解风险的管理 | ||||
ACQ.4.BP5：采取行动纠正偏差。当未达到商定的目标时采取行动。与供应商协商更改目标并在协议中记录。 | ||||
ACQ.4 供应商监控 | 成果1 | 成果2 | 成果3 | 成果4 |
输出信息项 | ||||
02-01 承诺/协议 | X | X | X | X |
13-52 沟通证据 | X | X | X | |
13-09 会议支持证据 | X | X | ||
13-14 进度状态 | X | X | ||
13-16 变更请求 | X | |||
13-19 评审证据 | X | |||
14-02 纠正措施 | X | |||
15-51 分析结果 | X | |||
基本实践 | ||||
BP1：商定并维护联合过程、联合接口和要交换的信息 | X | X | X | |
BP2：交换所有商定的信息 | X | X | X | |
BP3：与供应商一起评审开发工作产品 | X | X | X | |
BP4：评审供应商的进度 | X | X | X | |
BP5：采取行动纠正偏差 | X | X | ||
过程ID | |||||
SPL.2 | |||||
过程名称 | |||||
产品发布 | |||||
过程目的 | |||||
本过程的目的是控制产品向目标客户的发布。 | |||||
过程成果 | |||||
1) 确定产品发布的内容。 2) 从已配置项中组装发布包。 3) 定义并生成发布文档。 4) 根据已定义的标准执行发布审批。 5) 使发布包可供目标客户使用。 | |||||
基本实践 | |||||
SPL.2.BP1: 定义发布的功能。确定每次发布要包含的功能以及每次发布的发布标准。 注1：这可能包括发布所需的硬件元素、软件元素和额外的应用程序参数文件（影响已识别的系统功能）。 | |||||
SPL.2.BP2: 定义发布包。定义发布内容以及支持工具和信息。 注2：发布包可能还包括编程工具。 | |||||
SPL.2.BP3: 确保发布的唯一标识。根据发布的预期目的和期望，确保对发布进行唯一标识。 注3：可以通过产品发布的分类和编号方案来实现唯一标识。 | |||||
SPL.2.BP4: 从配置控制下的项构建发布。从配置控制下的项中构建发布，以确保完整性。 注4：此实践可能由SUP.8配置管理过程支持。 | |||||
SPL.2.BP5: 确保在交付前进行发布审批。在交付之前满足发布的标准。 | |||||
SPL.2.BP6: 提供发布说明。发布时附带详细说明发布关键特性的信息。 注5：发布说明可能包括关于法律方面的信息，如相关法律目标市场、所考虑的立法等。另见VAL.1验证。 | |||||
SPL.2.BP7: 沟通对发布的支持类型、服务水平和持续时间。确定并沟通对发布的支持类型、服务水平和持续时间。 | |||||
SPL.2.BP8: 将发布包交付给目标客户。将发布包交付给目标客户。 注6：目标客户可能是内部组织单位或外部组织。 | |||||
SPL.2 产品发布 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 |
输出信息项 | |||||
11-03 发布说明 | X | X | X | X | |
11-04 产品发布包 | X | X | |||
13-06 交付证据 | X | X | |||
13-13 产品发布审批 | X | X | |||
18-06 产品发布标准 | X | X | X | ||
基本实践 | |||||
BP1: 定义发布的功能内容 | X | ||||
BP2: 定义发布包 | X | ||||
BP3: 建立产品发布分类和 编号方案 | X | ||||
BP4: 从配置项构建发布 | X | ||||
BP5: 确保在交付前进行产品 发布审批 | X | ||||
BP6: 提供发布说明 | X | X | |||
BP7: 沟通对发布的支持类型 、服务水平和持续时间 | X | X | |||
BP8: 将发布包交付给目标客户 | X | ||||
过程ID | ||||
SYS.1 | ||||
过程名称 | ||||
需求挖掘 | ||||
过程目的 | ||||
本过程的目的是在整个产品和/或服务的生命周期中收集、分析和跟踪不断变化的利益相关方需要和需求，以建立一套商定的需求。 | ||||
过程成果 | ||||
1) 与利益相关方的持续沟通已建立。 2) 利益相关方的期望得到理解，并定义和商定了相关需求。 3) 对因利益相关方需要而产生的利益相关方需求变更进行分析，以便进行相关的风险评估和影响管理。 4) 确保确定所有受影响方的利益相关方需求状态。 | ||||
基本实践 | ||||
SYS.1.BP1: 获取利益相关方的期望和请求。通过直接征求利益相关方的意见，审查利益相关方的业务提案（如相关）和其他包含利益相关方需求输入的文件，并考虑目标运营和硬件环境，来获取和定义利益相关方的期望和请求。 注1：记录利益相关方或利益相关方需求的来源，支持利益相关方需求协议和变更分析（参见BP2和BP3）。 | ||||
SYS.1.BP2: 商定需求。将利益相关方的期望和请求正式化为需求。通过从所有受影响方获得明确协议，就利益相关方需求集达成共同理解。 注2：受影响方的例子包括客户、供应商、设计合作伙伴、合资伙伴或外包方。 注3：商定的利益相关方需求可能基于可行性研究和/或成本和进度影响分析。 | ||||
SYS.1.BP3: 分析利益相关方需求的变更。根据商定的利益相关方需求对利益相关方需求的所有变更进行分析。评估影响和风险，并启动适当的变更控制和缓解措施。 注4：需求变更可能源于不同的来源，例如技术变化、利益相关方需要或法律约束。 注5：如需要，请参阅SUP.10变更请求管理。 | ||||
SYS.1.BP4: 沟通需求状态。确保所有受影响方都能了解其需求的状态和处置情况，包括变更，并能沟通必要的信息和数据。 | ||||
SYS.1 需求挖掘 | 成果1 | 成果2 | 成果3 | 成果4 |
输出信息项 | ||||
15-51 分析结果 | X | |||
13-52 沟通证据 | X | X | ||
17-00 需求 | X | |||
17-54 需求属性 | X | X | ||
基本实践 | ||||
BP1: 获取利益相关方的期望和请求 | X | |||
BP2: 商定需求 | X | |||
BP3: 分析利益相关方需求的变更 | X | |||
BP4: 沟通需求状态 | X | X | ||
过程ID | ||||||
SYS.2 | ||||||
过程名称 | ||||||
系统需求分析 | ||||||
过程目的 | ||||||
目的是建立一套与利益相关方要求一致、结构化且经过分析的系统需求。 | ||||||
过程成果 | ||||||
1) 系统需求已明确。 2) 系统需求已结构化并排序。 3) 对系统需求的正确性和技术可行性进行了分析。 4) 分析了系统需求对运行环境的影响。 5) 在系统需求和利益相关方需求之间建立了一致性和双向可追溯性。 6) 系统需求已得到同意并已通知所有受影响方。 | ||||||
基本实践 | ||||||
SYS.2.BP1: 明确系统需求。根据已定义的需求特性，使用利益相关方需求来识别和记录系统的功能性和非功能性需求。 注1: 需求特性在ISO IEEE 29148、ISO 26262-8:2018或INCOSE需求编写指南等标准中定义。 注2: 技术标准共有的已定义需求特性示例包括可验证性（即，验证标准内在于需求文本中）、明确性/可理解性、无设计和实施限制，以及不与其他任何需求相矛盾。 | ||||||
SYS.2.BP2: 构造系统需求。对系统需求进行构造和排序。 注3: 构造标准的示例可以是分组（例如，按功能）或产品变体识别。 注4: 可以根据项目或利益相关方的需求，通过定义发布范围等方式来进行排序。请参阅SPL.2.BP1。 | ||||||
SYS.2.BP3: 分析系统需求。分析已明确的系统需求及其相互依赖性，以确保正确性和技术可行性，并支持项目管理层进行项目估算。 注5: 关于项目可行性和项目估算，请参阅MAN.3.BP3和MAN.3.BP5。 注6: 技术可行性可以基于平台或产品线，或者通过原型开发或产品演示器进行评估。 | ||||||
SYS.2.BP4: 分析对系统环境的影响。分析系统需求对相关系统环境中元素的影响。 | ||||||
SYS.2.BP5: 确保一致性并建立双向可追溯性。确保系统需求和利益相关方需求之间的一致性，并建立双向可追溯性。 注7: 双向可追溯性支持一致性，便于对变更请求进行影响分析，并支持展示对利益相关方需求的覆盖情况。仅存在链接并不一定意味着信息是相互一致的。 注8: 可能存在系统需求无法追溯到的非功能性利益相关方需求。例如过程需求。此类利益相关方需求仍需进行验证。 | ||||||
SYS.2.BP6: 传达已同意的系统需求和对系统环境的影响。向所有受影响方传达已同意的系统需求，以及对系统环境影响的分析结果。 | ||||||
SYS.2 系统需求分析 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 | 成果6 |
输出信息项 | ||||||
17-00 需求 | X | X | ||||
17-54 需求属性 | X | X | ||||
15-51 分析结果 | X | X | ||||
13-51 一致性证据 | X | |||||
13-52 沟通证据 | X | |||||
基本实践 | ||||||
BP1: 明确系统需求 | X | |||||
BP2: 构造系统需求 | X | |||||
BP3: 分析系统需求 | X | |||||
BP4: 分析对系统环 境的影响 | X | |||||
BP5: 确保一致性并 建立双向可追溯性 | X | |||||
BP6: 传达已同意的 系统需求和对系统环境的影响 | X | |||||
过程ID | ||||
SYS.3 | ||||
过程名称 | ||||
系统架构设计 | ||||
过程目的 | ||||
目的是建立一个分析后的系统架构，包括静态和动态方面，与系统需求保持一致。 | ||||
过程成果 | ||||
1) 设计了一个系统架构，包括系统元素及其行为、接口、关系和交互的定义。 2) 根据定义的标准对系统架构进行分析，并识别出特殊特性。 3) 在系统架构和系统需求之间建立一致性和双向可追溯性。 4) 将商定的系统架构和特殊特性传达给所有相关方。 | ||||
基本实践 | ||||
SYS.3.BP1: 指定系统架构的静态方面。根据功能和非功能系统需求，指定并文档化系统架构的静态方面，包括外部接口和一组定义的系统元素及其接口和关系。 | ||||
SYS.3.BP2: 指定系统架构的动态方面。根据功能和非功能系统需求，指定并文档化系统架构的动态方面，包括系统元素的行为及其在不同系统模式下的交互。 注1：系统元素交互的示例包括反映机械部件惯性的时序图、ECU的处理时间以及总线系统的信号传播时间。 | ||||
SYS.3.BP3: 分析系统架构。分析系统架构与产品生命周期相关的相关技术设计方面，以支持项目管理在项目估算方面的工作，并为非软件系统元素导出特殊特性。为系统架构设计决策提供理由。 注2：有关项目可行性和项目估算的信息，请参阅MAN.3.BP3和MAN.3.BP5。 注3：产品生命周期阶段的示例包括生产、维护和修理、报废。 注4：技术方面的示例包括生产的可制造性、预先存在的系统元素的再利用适用性或系统元素的可用性。 注5：适用于分析技术方面的方法示例包括原型、模拟和定性分析（例如，FMEA方法）。 注6：设计理由的示例包括经验证的使用、产品平台或产品线的重用、自制或购买的决策，或以进化的方式发现（例如，基于集合的设计）。 | ||||
SYS.3.BP4: 确保一致性和建立双向可追溯性。确保系统架构元素与系统需求之间的一致性和双向可追溯性，这些需求代表物理最终产品的属性或特性。 注7：双向可追溯性进一步支持一致性，便于分析变更请求的影响，并展示验证的覆盖范围。仅可追溯性（例如，链接的存在）并不一定意味着信息之间是一致的。 注8：可能存在一些非功能需求，这些需求并不追溯到系统架构设计。示例是不处理或不表示物理最终产品的直接属性或特性。这些需求仍然需要进行验证。 | ||||
SYS.3.BP5: 传达商定的系统架构。将商定的系统架构（包括特殊特性）传达给所有相关方。 | ||||
SYS.3 系统架构设计 | 成果1 | 成果2 | 成果3 | 成果4 |
输出信息项 | ||||
04-06 系统架构 | X | |||
13-51 一致性证据 | X | |||
13-52 沟通证据 | X | |||
15-51 分析结果 | X | |||
17-57 特殊特性 | X | |||
基本实践 | ||||
BP1: 指定系统架构的静态方面 | X | |||
BP2: 指定系统架构的动态方面 | X | |||
BP3: 分析系统架构 | X | |||
BP4: 确保一致性和建立双向可追溯性 | X | |||
BP5: 传达商定的系统架构 | X | |||
过程ID | |||||||
SYS.4 | |||||||
过程名称 | |||||||
系统集成与集成验证 | |||||||
过程目的 | |||||||
目的是集成系统元素，并验证集成的系统元素与系统架构的一致性。 | |||||||
过程成果 | |||||||
1) 根据系统架构，包括系统元素的接口及其交互，为集成系统元素的系统集成验证指定验证措施。 2) 根据发布范围，将系统元素集成到一个完整的集成系统中。 3) 根据发布范围，考虑包括回归验证准则在内的选择准则，选择验证措施。 4) 使用所选的验证措施验证集成的系统元素，并记录系统集成验证的结果。 5) 在验证措施和系统架构元素之间建立一致性和双向可追溯性。 6) 在验证结果和验证措施之间建立双向可追溯性。 7) 总结系统集成和集成验证的结果，并将其传达给所有受影响的相关方。 | |||||||
基本实践 | |||||||
SYS.4.BP1: 指定系统集成验证措施。根据系统元素针对系统架构的静态和动态方面的集成所定义的顺序和先决条件，指定验证措施，包括： l 验证措施的技术； l 验证措施的通过/失败准则； l 验证措施的进入和退出准则的定义； l 所需的验证基础设施和环境设置。 注1：验证措施可能关注的示例是接口系统元素之间正确信号流的时序依赖关系，或系统架构中指定的硬件和软件之间的交互。系统集成测试用例可能关注： l 系统项之间的正确信号流； l 系统项之间信号流的及时性和时序依赖性； l 所有使用接口的系统项对信号的正确解释； l 以及/或系统项之间的动态交互。 | |||||||
SYS.4.BP2: 选择验证措施。记录每个集成步骤的验证措施选择，考虑包括回归验证准则在内的选择准则。根据发布范围，记录的验证措施选择应具有足够的覆盖范围。 注2：选择准则的示例可以是需求的优先级、回归验证的需要（例如，由于系统架构设计或系统组件的更改），或交付产品发布的预期用途（例如，试验台、试验场、公共道路等）。 | |||||||
SYS.4.BP3: 集成系统元素并执行集成验证。根据指定的接口和系统元素之间的交互，以及定义的顺序和定义的先决条件，集成系统元素，直到系统完全集成。执行所选的系统集成验证措施。记录验证措施数据，包括通过/失败状态和相应的验证措施数据。 注3：开始系统集成的先决条件的示例可以是成功的系统元素验证或预先存在的系统元素的资格鉴定。 注4：参见SUP.9处理与预期结果不符的验证结果。 | |||||||
SYS.4.BP4: 确保一致性并建立双向可追溯性。确保验证措施与系统架构之间的一致性，并建立双向可追溯性。在验证结果和验证措施之间建立双向可追溯性。 注5：双向可追溯性支持一致性，便于变更请求的影响分析，以及验证覆盖范围的演示。仅可追溯性（例如，链接的存在）并不一定意味着信息之间相互一致。 | |||||||
SYS.4.BP5: 总结并沟通结果。总结系统集成和集成验证的结果，并将其传达给所有受影响的相关方。 注6：在摘要中提供测试用例执行的所有必要信息，使其他方能够判断后果。 | |||||||
SYS.4 系统集成与集成验证 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 | 成果6 | 成果7 |
输出信息项 | |||||||
08-60 验证措施 | X | ||||||
06-50 集成顺序说明 | X | ||||||
03-50 验证措施数据 | X | ||||||
08-58 验证措施 选择集 | X | ||||||
15-52 验证结果 | X | ||||||
13-51 一致性证据 | X | X | |||||
13-52 沟通证据 | X | ||||||
11-06 集成系统 | X | ||||||
基本实践 | |||||||
BP1: 指定系统集 成的验证措施 | X | ||||||
BP2: 选择验证措施 | X | ||||||
BP3: 集成系统元 素并执行集成验证 | X | X | |||||
BP4: 确保一致性 并建立双向追溯性 | X | X | |||||
BP5: 总结并沟通结果 | X | ||||||
过程ID | ||||||
SYS.5 | ||||||
过程名称 | ||||||
系统验证 | ||||||
过程目的 | ||||||
该过程的目的是确保系统经过验证，与系统需求保持一致。 | ||||||
过程成果 | ||||||
1) 根据系统需求，为系统的系统验证指定验证措施。 2) 根据发布范围考虑标准（包括回归验证标准）来选择验证措施。 3) 使用选定的验证措施对集成系统进行验证，并记录系统验证的结果。 4) 在验证措施和系统需求之间建立一致性和双向追溯性。 5) 在验证结果和验证措施之间建立双向追溯性。 6) 总结验证结果，并与所有受影响方进行沟通。 | ||||||
基本实践 | ||||||
SYS.5.BP1: 指定系统验证的验证措施。明确系统验证的验证措施，以提供符合系统需求中功能性和非功能性信息的证据，包括： l 验证措施的技术； l 验证措施的通过/失败标准； l 验证措施的进入和退出标准定义； l 验证措施的必要顺序； l 所需的验证基础设施和环境设置。 注1：系统验证措施可能涵盖热、环境、稳健性/寿命和EMC等方面。 | ||||||
SYS.5.BP2: 选择验证措施。记录考虑选择标准（包括回归验证标准）的验证措施选择。根据发布范围，验证措施的选择应具有足够的覆盖率。 注2：选择标准示例可以是需求的优先级、回归验证的需要（例如，由于系统需求的变化）、交付产品发布的预期用途（试验台、试验场、公共道路等）。 | ||||||
SYS.5.BP3: 执行集成系统的验证。使用选定的验证措施对集成系统进行验证。记录验证结果，包括通过/失败状态和相应的验证措施数据。 注3：有关处理与预期结果不符的验证结果，请参见SUP.9。 | ||||||
SYS.5.BP4: 确保一致性并建立双向追溯性。确保验证措施和系统需求之间的一致性，并建立双向追溯性。在验证结果和验证措施之间建立双向追溯性。 注4：双向追溯性支持一致性，便于分析变更请求的影响，并展示验证覆盖率。仅存在链接并不意味着信息之间相互一致。 | ||||||
SYS.5.BP5: 总结并沟通结果。总结系统验证结果，并与所有受影响方进行沟通。 注5：在总结中提供测试用例执行的所有必要信息，使其他方能够判断后果。 | ||||||
SYS.5 系统验证 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 | 成果6 |
输出信息项 | ||||||
08-60 验证措施 | X | |||||
03-50 验证措施数据 | X | |||||
08-58 验证措施选择集 | X | |||||
15-52 验证结果 | X | |||||
13-51 一致性证据 | X | X | ||||
13-52 沟通证据 | X | |||||
基本实践 | ||||||
BP1: 指定系统验证的验证措施 | X | |||||
BP2: 选择验证措施 | X | |||||
BP3: 执行集成系统的验证 | X | |||||
BP4: 确保一致性并建立双向追溯性 | X | X | ||||
BP5: 总结并沟通结果 | X | |||||
过程ID | |||||||
SWE.1 | |||||||
过程名称 | |||||||
软件需求分析 | |||||||
过程目的 | |||||||
目的是建立一套与系统需求和系统架构相一致的、经过结构化分析的软件需求。 | |||||||
过程成果 | |||||||
1) 软件需求得到明确。 2) 软件需求得到结构化处理和优先排序。 3) 对软件需求的正确性和技术可行性进行了分析。 4) 分析了软件需求对运行环境的影响。 5) 在软件需求和系统需求之间建立了一致性和双向可追溯性。 6) 在软件需求和系统架构之间建立了一致性和双向可追溯性。 7) 软件需求经过协商并传达给了所有相关方。 | |||||||
基本实践 | |||||||
SWE.1.BP1：明确软件需求。根据已定义的需求特性，使用系统需求和系统架构来确定和记录软件的功能性和非功能性需求。 注1：需求的特性在诸如ISO IEEE 29148、ISO 26262-8:2018或INCOSE的《需求编写指南》等标准中定义。 注2：技术标准所共享的已定义需求特性的例子包括可验证性（即验证标准内在于需求文本中）、明确性/可理解性、不受设计和实施的影响，以及不与其他任何需求相矛盾。 注3：在仅进行软件开发的情况下，系统需求和系统架构指的是给定的操作环境。在这种情况下，利益相关方的需求可以作为确定软件所需功能和能力的基础。 注4：硬件-软件接口（HSI）定义将硬件置于上下文中，因此它是系统设计层面的接口决策。如果存在这样的HSI，那么它可能为软件需求提供输入。SWE.1.BP2：构建软件需求结构。构建并优先处理软件需求。 注5：结构化标准的例子可以是分组（例如，按功能）或表达产品变体。 注6：可以根据项目或利益相关方的需要通过定义发布范围等方式进行优先排序。参见SPL.2.BP1。 | |||||||
SWE.1.BP3：分析软件需求。分析已明确的软件需求及其相互依赖性，以确保正确性、技术可行性，并支持项目管理关于项目估算的工作。 注7：关于项目可行性和项目估算，分别参见MAN.3.BP3和MAN.3.BP5。 注8：技术可行性可以基于平台或产品线进行评估，或者通过原型制作进行评估。 | |||||||
SWE.1.BP4：分析对操作环境的影响。分析软件需求将对操作环境中的元素产生的影响。 | |||||||
SWE.1.BP5：确保一致性和建立双向可追溯性。确保软件需求和系统架构之间的一致性和双向可追溯性。确保软件需求和系统需求之间的一致性和双向可追溯性。 注9：不希望出现冗余的可追溯性。 注10：可能存在一些非功能性的系统需求，这些需求在软件需求中并没有追溯。例如，过程需求或与软件产品生命周期后期阶段（如事件处理）相关的需求。这些需求仍然需要进行验证。 注11：双向可追溯性支持一致性，有助于分析变更请求的影响，以及展示验证的覆盖范围。仅存在可追溯性（例如链接的存在）并不一定意味着信息之间是一致的。 注12：在仅进行软件开发的情况下，系统需求和系统架构指的是给定的操作环境。在这种情况下，可以在利益相关方需求和软件需求之间确保一致性和双向可追溯性。 | |||||||
SWE.1.BP6：传达商定的软件需求和对操作环境的影响。将所有受影响的方面已商定的软件需求和对操作环境分析的结果进行传达。 | |||||||
SWE.1 软件需求分析 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 | 成果6 | 成果7 |
输出信息项 | |||||||
17-00 需求 | X | X | |||||
17-54 需求属性 | X | ||||||
15-51 分析结果 | X | X | |||||
13-51 一致性证据 | X | X | |||||
13-52 沟通证据 | X | ||||||
基本实践 | |||||||
BP1：明确软件需求 | X | ||||||
BP2：构建软件需求 结构 | X | ||||||
BP3：分析软件需求 | X | ||||||
BP4：分析对操作 环境的影响 | X | ||||||
BP5：确保一致性 和建立双向可追溯性 | X | X | |||||
BP6：传达商定的 软件需求和对操作环境的影响 | X | ||||||
过程ID | ||||
SWE.2 | ||||
过程名称 | ||||
软件架构设计 | ||||
过程目的 | ||||
目的是建立一个与软件需求一致的、包含静态和动态方面的分析型软件架构。 | ||||
过程成果 | ||||
1) 设计了一个包含静态和动态方面的软件架构。 2) 根据定义的标准对软件架构进行了分析。 3) 在软件架构和软件需求之间建立了一致性和双向可追溯性。 4) 与所有相关方就软件架构达成了一致并进行了沟通。 | ||||
基本实践 | ||||
SWE.2.BP1: 规定软件架构的静态方面。根据功能和非功能软件需求，规定并记录软件架构的静态方面，包括外部接口和一组已定义的软件组件及其接口和关系。 注1: 硬件-软件接口(HSI)定义将硬件设计置于上下文中，因此是系统设计(SYS.3)的一个方面。 | ||||
SWE.2.BP2: 规定软件架构的动态方面。根据功能和非功能软件需求，规定并记录软件架构的动态方面，包括软件组件的行为及其在不同软件模式下的交互，以及并发性方面。 注2: 并发性方面的例子有与应用相关的中断处理、抢占式处理、多线程。 注3: 行为描述的例子有自然语言或半形式化表示法(例如，SysML、UML)。 | ||||
SWE.2.BP3: 分析软件架构。根据相关技术设计方面分析软件架构，并在项目估算方面支持项目管理。记录软件架构设计决策的理由。 注4: 参见MAN.3.BP3了解项目可行性，参见MAN.3.BP5了解项目估算。 注5: 分析可能包括当前应用中预先存在的软件组件的适用性。 注6: 适合分析技术方面的方法的例子有原型、模拟、定性分析。 注7: 技术方面的例子有功能、时序和资源消耗(例如，ROM、RAM、外部/内部EEPROM或Data Flash或CPU负载)。 注8: 设计理由可以包括诸如经实践证明的、重用软件框架或软件产品线、自制或购买决策，或以进化的方式找到的理由(例如，基于集合的设计)。 | ||||
SWE.2.BP4: 确保一致性和建立双向可追溯性。确保软件架构和软件需求之间的一致性和双向可追溯性。 注9: 可能存在软件架构设计不追溯的非功能软件需求。例如，开发过程需求。这些需求仍然需要进行验证。 注10: 双向可追溯性支持一致性，有助于分析变更请求的影响，并展示验证的覆盖范围。仅可追溯性，例如链接的存在，并不一定意味着信息是相互一致的。 | ||||
SWE.2.BP5: 沟通商定的软件架构。与所有相关方沟通商定的软件架构。 | ||||
SWE.2 软件架构设计 | 成果1 | 成果2 | 成果3 | 成果4 |
输出信息项 | ||||
04-04 软件架构 | X | |||
13-51 一致性证据 | X | |||
13-52 沟通证据 | X | |||
15-51 分析结果 | X | |||
基本实践 | ||||
BP1: 规定软件架构的静态方面 | X | |||
BP2: 规定软件架构的动态方面 | X | |||
BP3: 分析软件架构 | X | |||
BP4: 确保一致性和建立双向可追溯性 | X | |||
BP5: 沟通商定的软件架构 | X | |||
过程ID | ||||
SWE.3 | ||||
过程名称 | ||||
软件详细设计与单元构建 | ||||
过程目的 | ||||
本过程的目的是建立一个包含静态和动态方面的软件详细设计，该设计与软件架构保持一致，并根据软件详细设计构建软件单元。 | ||||
过程成果 | ||||
1) 规定了包含静态和动态方面的详细设计。 2) 生产了软件详细设计中规定的软件单元。 3) 在软件详细设计与软件架构之间建立了一致性和双向可追溯性；在源代码与软件详细设计之间建立了一致性和双向可追溯性；在软件详细设计与软件需求之间建立了一致性和双向可追溯性。 4) 将源代码和商定的软件详细设计传达给所有受影响的相关方。 | ||||
基本实践 | ||||
SWE.3.BP1：规定详细设计的静态方面。为每个软件组件规定其软件单元的行为、静态结构和关系、接口，包括： l 输入和输出的有效数据值范围（从应用领域角度看） l 适用于输入和输出的物理或测量单位（从应用领域角度看） 注1：软件单元的边界与其在源代码、代码文件结构或基于模型的实现中的表示无关。它更多地是由应用领域视角的语义驱动的。因此，在代码级别上，软件单元可能由单个子程序或一组子程序表示。 注2：从应用领域角度看，带有适用物理单位的有效数据值范围的示例有‘0..200 [m/s]’、‘0..3.8 [A]’或‘1..100 [N]’。有关将此类应用领域值范围映射到编程语言级别的数据类型（如值范围为0..65535的无符号整数），请参阅BP2。 注3：测量单位的示例有‘%’或‘‰’。 注4：计数器是一个参数或返回值的示例，它既不适用于物理单位也不适用于测量单位。 注5：硬件-软件接口（HSI）定义将硬件设计置于上下文中，因此是系统设计（SYS.3）的一个方面。 | ||||
SWE.3.BP2：规定详细设计的动态方面。根据软件架构规定和记录详细设计的动态方面，包括相关软件单元之间的交互，以实现组件的动态行为。 注6：行为描述的示例有自然语言或半形式化表示法（例如，SysML、UML）。 | ||||
SWE.3.BP3：开发软件单元。根据详细设计和编码原则开发并记录软件单元。 注7：能力等级1的编码原则示例包括不使用隐式类型转换、子程序中只有一个入口和一个出口点以及范围检查（设计合约、防御性编程）。更多示例参见例如ISO 26262-6第8.4.5条以及表6。 | ||||
SWE.3.BP4：确保一致性并建立双向可追溯性。确保软件详细设计与软件架构之间的一致性并建立双向可追溯性。确保开发的软件单元与软件详细设计之间的一致性并建立双向可追溯性。确保软件详细设计与软件需求之间的一致性并建立可追溯性。 注8：应避免冗余，通过结合这些方法来实现。 注9：将详细设计中的软件单元直接追溯到软件需求的示例有通信矩阵或基础软件方面，例如Autosar配置中固有的诊断标识符列表。 注10：双向可追溯性支持一致性，便于分析变更请求的影响以及验证覆盖率的展示。仅可追溯性（例如链接的存在）并不一定意味着信息之间是一致的。 | ||||
SWE.3.BP5：传达商定的软件详细设计和开发的软件单元。将商定的软件详细设计和开发的软件单元传达给所有相关方。 | ||||
SWE.3 软件详细设计和单元构建 | 成果1 | 成果2 | 成果3 | 成果4 |
输出信息项 | ||||
04-05 软件详细设计 | X | |||
11-05 软件单元 | X | X | ||
13-51 一致性证据 | X | |||
13-52 通信证据 | X | |||
基本实践 | ||||
BP1：规定详细设计的静态方面 | X | |||
BP2：规定详细设计的动态方面 | X | |||
BP3：开发软件单元 | X | |||
BP4：确保一致性并建立双向可追溯性 | X | |||
BP5：传达商定的软件详细设计和开发的软件单元 | X | |||
过程ID | |||||
SWE.4 | |||||
过程名称 | |||||
软件单元验证 | |||||
过程目的 | |||||
目的是验证软件单元是否与软件详细设计保持一致。 | |||||
过程成果 | |||||
1) 指定了软件单元验证的验证措施。 2) 根据发布范围选择了软件单元验证措施，包括回归验证的标准。 3) 使用所选的验证措施对软件单元进行验证，并记录结果。 4) 在验证措施和软件单元之间建立一致性和双向可追溯性；在验证结果和验证措施之间建立双向可追溯性。 5) 总结软件单元验证的结果，并与所有受影响方进行沟通。 | |||||
基本实践 | |||||
SWE.4.BP1: 指定软件单元验证措施。为软件详细设计中定义的每个软件单元指定验证措施，包括： l 验证措施的通过/失败标准， l 验证措施的进入和退出标准，以及 l 所需的验证基础设施。 注1: 单元验证措施的例子包括静态分析、代码审查和单元测试。 注2: 静态分析可以根据MISRA规则集和其他编码标准进行。 | |||||
SWE.4.BP2: 选择软件单元验证措施。记录考虑选择标准的验证措施的选择，包括回归验证的标准。根据发布范围，记录的验证措施选择应具有足够的覆盖范围。 | |||||
SWE.4.BP3: 验证软件单元。使用所选的验证措施执行软件单元验证。记录验证结果，包括通过/失败状态和相应的验证措施数据。 注3: 参见SUP.9处理偏离预期结果的验证结果。 | |||||
SWE.4.BP4: 确保一致性并建立双向可追溯性。确保验证措施与详细设计中定义的软件单元之间的一致性，并建立双向可追溯性。在验证结果和验证措施之间建立双向可追溯性。 注4: 双向可追溯性支持一致性，便于分析变更请求的影响，并展示验证覆盖范围。仅存在链接并不一定意味着信息之间相互一致。 | |||||
SWE.4.BP5: 总结并沟通结果。总结软件单元验证的结果，并与所有受影响方进行沟通。 注5: 在摘要中提供测试用例执行的所有必要信息，使其他方能够判断结果。 | |||||
SWE.4 软件单元验证 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 |
输出信息项 | |||||
08-60 验证措施 | X | ||||
03-50 验证措施数据 | X | ||||
08-58 验证措施选择集 | X | ||||
15-52 验证结果 | X | ||||
13-51 一致性证据 | X | ||||
13-52 沟通证据 | X | ||||
基本实践 | |||||
BP1: 指定软件单元验证措施 | X | ||||
BP2: 选择软件单元验证措施 | X | ||||
BP3: 验证软件单元 | X | ||||
BP4: 确保软件单元验证的一致性和建立双向可追溯性 | X | ||||
BP5: 总结并沟通结 | X | ||||
过程ID | ||||||||
SWE.5 | ||||||||
过程名称 | ||||||||
软件组件验证与集成验证 | ||||||||
过程目的 | ||||||||
本过程的目的是验证软件组件是否与软件架构设计保持一致，并集成软件元素，验证集成后的软件元素是否与软件架构和软件详细设计保持一致。 | ||||||||
过程成果 | ||||||||
1) 基于软件架构和详细设计，为集成后的软件元素的软件集成验证指定验证措施，包括软件组件之间的接口和交互。 2) 指定软件组件的验证措施，以提供软件组件符合软件组件行为和接口的证据。 3) 将软件元素集成到一个完整的集成软件中。 4) 根据发布范围选择验证措施，考虑标准，包括回归验证的标准。 5) 使用所选的验证措施对软件组件进行验证，并记录集成验证的结果。 6) 使用所选的验证措施对集成后的软件元素进行验证，并记录集成验证的结果。 7) 在验证措施与软件架构和详细设计之间建立一致性和双向可追溯性；在验证结果与验证措施之间建立双向可追溯性。 8) 总结软件组件验证和软件元素集成验证的结果，并与所有受影响方进行沟通。 | ||||||||
基本实践 | ||||||||
SWE.5.BP1: 指定软件集成验证措施。根据软件元素集成的定义顺序和先决条件，针对软件架构定义的静态和动态方面指定验证措施，包括： l 验证措施的技术， l 验证措施的通过/失败标准， l 验证措施的进入和退出标准，以及 l 所需的验证基础设施和环境设置。 注1: 软件集成验证措施可能关注的例子包括软件组件之间的正确数据流和动态交互以及它们的时序依赖关系、所有软件组件使用接口对数据的正确解释以及对资源消耗目标的符合性。 注2: 软件集成验证措施可以使用硬件调试接口或仿真环境（例如，软件在环仿真）来支持。 | ||||||||
SWE.5.BP2: 指定验证软件组件行为的验证措施。针对软件架构中定义的软件组件的行为和接口，指定软件组件验证的验证措施，包括： l 验证措施的技术， l 验证措施的进入和退出标准， l 验证措施的通过/失败标准，以及 l 所需的验证基础设施和环境设置。 注3: 验证措施与软件组件相关，但与软件单元无关，因为软件单元验证在SWE.4软件单元验证过程中进行处理。 | ||||||||
SWE.5.BP3：选择验证措施。为每个集成步骤记录所选的集成验证措施，考虑包括回归验证标准在内的选择标准。根据发布范围，所记录的验证措施选择应具有足够的覆盖范围。 注4：选择标准的示例可以是持续集成/持续开发回归验证的需要（例如，由于软件架构或详细设计的更改），或所交付产品版本的预期用途（例如，试验台、试验场、公共道路等）。 | ||||||||
SWE.5.BP4：集成软件元素并执行集成验证。根据软件元素之间指定的接口和交互，以及定义的序列和定义的先决条件，将软件元素集成，直到软件完全集成。执行所选的集成验证措施。记录验证措施数据，包括通过/失败状态和相应的验证措施数据。 注5：开始软件集成的先决条件示例包括预先存在的软件组件、现成的软件组件、开源软件或自动生成的软件的资格认证。 注6：定义的先决条件可能允许例如所有软件组件的大爆炸集成、持续集成，以及伴随验证措施的逐步集成（例如，跨软件单元和/或软件组件到完全集成的软件）。 注7：参见SUP.9处理验证结果与预期结果有偏差的情况。 | ||||||||
SWE.5.BP5：执行软件组件验证。执行所选的验证措施以验证软件组件的行为。记录验证结果，包括通过/失败状态和相应的验证措施数据。 注8：参见SUP.9处理与预期结果有偏差的验证结果。 | ||||||||
SWE.5.BP6：确保一致性并建立双向可追溯性。确保验证措施与软件架构和详细设计的静态和动态方面之间的一致性，并建立双向可追溯性。在验证结果和验证措施之间建立双向可追溯性。 注9：双向可追溯性支持一致性，便于分析变更请求的影响，并展示验证覆盖范围。仅可追溯性（例如，链接的存在）并不一定意味着信息之间是一致的。 | ||||||||
SWE.5.BP7：总结和沟通结果。总结软件组件验证和软件集成验证结果，并与所有受影响方进行沟通。 注10：在摘要中提供测试用例执行的所有必要信息，使其他方能够判断后果。 | ||||||||
SWE.5 软件组件验 证和集成验证 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 | 成果6 | 成果7 | 成果8 |
输出信息项 | ||||||||
08-60 验证措施 | X | X | ||||||
06-50 集成序列指令 | X | |||||||
03-50 验证措施数据 | X | |||||||
08-58 验证措施选择集 | X | |||||||
15-52 验证结果 | X | X | ||||||
13-51 一致性证据 | X | |||||||
13-52 沟通证据 | X | |||||||
01-03 软件组件 | X | |||||||
01-50 集成软件 | X | |||||||
基本实践 | ||||||||
BP1：指定软件集成验证措施 | X | |||||||
BP2：指定验证软件组件行为的验证措施 | X | |||||||
BP3：选择验证措施 | X | |||||||
BP4：集成软件元素 并执行集成验证 | X | X | ||||||
BP5：执行软件组件 验证 | X | |||||||
BP6：确保一致性并 建立双向可追溯性 | X | |||||||
BP7：总结和沟通结果 | X | |||||||
过程ID | |||||
SWE.6 | |||||
过程名称 | |||||
软件验证 | |||||
过程目的 | |||||
软件验证过程的目的是确保集成软件经过验证与软件需求保持一致。 | |||||
过程成果 | |||||
1) 根据软件需求，为软件的软件验证指定验证措施。 2) 根据发布范围考虑标准（包括回归验证标准）选择验证措施。 3) 使用选定的验证措施对集成软件进行验证，并记录软件验证的结果。 4) 在验证措施和软件需求之间建立一致性和双向可追溯性；在验证结果和验证措施之间建立双向可追溯性。 5) 总结软件验证结果并与所有受影响方进行沟通。 | |||||
基本实践 | |||||
SWE.6.BP1: 指定软件验证的验证措施。指定适用于为集成软件与软件需求中的功能和非功能信息的一致性提供证据的验证措施，包括： l 验证措施的技术， l 验证措施的通过/失败标准， l 验证措施的进入和退出标准的定义， l 验证措施的必要顺序，以及 l 所需的验证基础设施和环境设置。 注1：为验证措施选择适当的技术可能取决于各自软件需求的内容（例如，面向数据范围的需求的边界值和等价类，正面/晴天测试与负面测试，如故障注入），或基于需求的测试与“基于知识或经验的错误猜测”。 | |||||
SWE.6.BP2: 选择验证措施。记录考虑选择标准（包括回归验证标准）的验证措施的选择。根据发布范围，记录的验证措施选择应具有足够的覆盖范围。 注2：选择标准的示例可以是需求的优先级、持续开发、回归验证的需要（例如，由于软件需求的变化）或交付产品版本的预期用途（试验台、试验场、公共道路等）。 | |||||
SWE.6.BP3: 验证集成软件。使用选定的验证措施执行集成软件的验证。记录验证结果，包括通过/失败状态和相应的验证措施数据。 注3：参见SUP.9处理与预期结果不符的验证结果。 | |||||
SWE.6.BP4: 确保一致性并建立双向可追溯性。确保验证措施和软件需求之间的一致性并建立双向可追溯性。在验证结果和验证措施之间建立双向可追溯性。 注4：双向可追溯性支持一致性，便于对变更请求进行影响分析，以及展示验证覆盖范围。仅可追溯性（例如，链接的存在）并不一定意味着信息之间相互一致。 | |||||
SWE.6.BP5: 总结并沟通结果。总结软件验证结果并与所有受影响方进行沟通。 注5：在摘要中提供测试用例执行的所有必要信息，使其他方能够判断后果。 | |||||
SWE.6 软件验证 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 |
输出信息项 | |||||
08-60 验证措施 | X | ||||
03-50 验证措施数据 | X | ||||
08-58 验证措施选择集 | X | ||||
15-52 验证结果 | X | ||||
13-51 一致性证据 | X | ||||
13-52 沟通证据 | X | ||||
基本实践 | |||||
BP1: 指定软件验证的验证措施 | X | ||||
BP2: 选择验证措施 | X | ||||
BP3: 验证集成软件 | X | ||||
BP4: 确保一致性并建立双向可追溯性 | X | ||||
BP5：总结和沟通结果 | X | ||||
过程ID | ||||
VAL.1 | ||||
过程名称 | ||||
确认 | ||||
过程目的 | ||||
本过程的目的是提供证据，证明允许最终用户直接交互的最终产品在其操作目标环境中满足预期使用要求。 | ||||
过程成果 | ||||
1) 选择确认措施时，考虑回归验证的标准。 2) 使用选定的确认措施对产品进行确认，并记录确认结果。 3) 在确认措施和利益相关方需求之间建立一致性和单向可追溯性；在确认结果和确认措施之间建立一致性和双向可追溯性。 4) 汇总确认结果，并与所有受影响方进行沟通。 | ||||
基本实践 | ||||
VAL.1.BP1: 指定产品确认的确认措施。根据利益相关方的需求，为最终产品指定确认措施，以提供证据表明其在操作目标环境中满足预期使用要求，包括： l 确认措施的技术； l 确认措施的通过/失败标准； l 确认措施的进入和退出标准定义； l 确认措施的必要顺序； l 所需的确认基础设施和环境设置。 注1：与确认相关的利益相关方需求的示例包括认证或法定类型批准要求。预期使用期望的来源的进一步示例是技术风险（参见MAN.5、SYS.3.BP4、SWE.2.BP3、HWE.2.BP6）。 注2：在无法全面指定或频繁更改利益相关方需求的情况下，可以对产品演化中（通常是快速开发的）增量进行重复确认，以完善利益相关方需求，并降低正确识别需求的风险。 注3：确认还可以进行，以证实产品也满足通常较少正式表达，但有时更重要的态度、经验和主观测试，这些包括利益相关方或最终用户的满意度。 | ||||
VAL.1.BP2: 选择确认措施。记录考虑选择标准的确认措施的选择，包括回归确认的标准。根据发布范围，所记录的确认措施选择应具有足够的覆盖范围。 注4：选择标准的示例可以是所交付产品的发布目的（如试验台、试验场、公共道路上的确认、最终用户的现场使用）、认证/类型批准、需求确认，或由于例如利益相关方需求和需求的变化而需要进行回归的情况。 | ||||
VAL.1.BP3: 执行确认并评估结果。使用选定的确认措施对集成最终产品进行确认。记录确认结果，包括通过/失败状态。评估确认结果。 注5：确认结果可作为识别利益相关方或系统需求的手段，例如在模型或概念研究的情况下。 注6：参见SUP.9处理与预期结果不符的验证结果。 | ||||
VAL.1.BP4: 确保一致性并建立双向可追溯性。确保从确认措施到得出它们的利益相关方需求的一致性，并建立双向可追溯性。在确认结果和确认措施之间建立双向可追溯性。 注7：确认措施的来源示例有法律要求、认证要求、技术风险分析结果，或利益相关方和系统要求（参见SYS.1和SYS.2）。 注8：如果确认措施的来源是例如法律或认证要求，那么从这些来源到确认措施的直接双向可追溯性是不可能的。在这种情况下，单向可追溯性就足够了。 注9：双向可追溯性支持一致性，促进变更请求的影响分析，以及验证覆盖率的展示。仅可追溯性（例如链接的存在）并不一定意味着信息是相互一致的。 | ||||
VAL.1.BP5: 汇总并沟通结果。汇总确认结果，并与所有受影响方进行沟通。 注10：在摘要中提供测试用例执行的所有必要信息，使其他方能够判断后果。 | ||||
VAL.1 确认 | 成果1 | 成果2 | 成果3 | 成果4 |
输出信息项 | ||||
08-59 确认措施 | X | |||
08-57 确认措施选择集 | X | |||
13-24 确认结果 | X | |||
13-51 一致性证据 | X | |||
13-52 沟通证据 | X | |||
基本实践 | ||||
BP1: 指定确认措施 | X | |||
BP2: 选择确认措施 | X | |||
BP3: 执行确认并评估结果 | X | |||
BP4: 确保一致性并建立可追溯性 | X | |||
BP5: 汇总并沟通结果 | X | |||
过程ID | ||||||
MLE.1 | ||||||
过程名称 | ||||||
机器学习需求分析 | ||||||
过程目的 | ||||||
将机器学习相关的软件需求细化为一套机器学习需求。 | ||||||
过程成果 | ||||||
1) 基于软件需求和软件架构的组成部分，识别和指定包括机器学习数据需求在内的机器学习需求。 2) 对机器学习需求进行结构化和优先级排序。 3) 分析机器学习需求的正确性和可验证性。 4) 分析机器学习需求对机器学习运行环境的影响。 5) 在机器学习需求与软件需求之间，以及在机器学习需求与软件架构之间建立一致性和双向可追溯性。 6) 就机器学习需求达成一致，并与所有受影响方进行沟通。 | ||||||
基本实践 | ||||||
MLE.1.BP1：指定机器学习需求。使用软件需求和软件架构来识别和指定功能和非功能的机器学习需求，以及指定数据特性（例如，性别、天气条件、ODD内的街道条件）及其预期分布的机器学习数据需求。 注1：非功能需求可能包括ODD和KPIs的相关特性，如稳健性、性能和可信度水平。 注2：机器学习数据需求是SUP.11机器学习数据管理的输入，但也是其他MLE过程的输入。 注3：在仅进行机器学习开发的情况下，利益相关方需求代表软件需求。 | ||||||
MLE.1.BP2：结构化机器学习需求。对机器学习需求进行结构化和优先级排序。 注4：结构化的标准示例可以是分组（例如，按功能）或变体识别。 注5：可以根据项目或利益相关方的需求，通过例如定义发布范围来进行优先级排序。参考SPL.2.BP1。 | ||||||
MLE.1.BP3：分析机器学习需求。分析指定的机器学习需求，包括它们的相互依赖性，以确保正确性、技术可行性和机器学习模型测试的能力，并支持项目管理关于项目估算的工作。 注6：关于项目可行性和项目估算，请参阅MAN.3.BP3和MAN.3.BP5。 | ||||||
MLE.1.BP4：分析对机器学习运行环境的影响。分析机器学习需求将对软件组件的接口和机器学习运行环境产生的影响。 注7：机器学习运行环境定义为训练和部署的机器学习模型执行所需的基础设施和信息。 | ||||||
MLE.1.BP5：确保一致性并建立双向可追溯性。确保机器学习需求与软件需求之间，以及机器学习需求与软件架构之间的一致性和双向可追溯性。 注8：双向可追溯性支持一致性，便于变更请求的影响分析，以及验证覆盖率的演示。仅可追溯性（例如，链接的存在）并不一定意味着信息是相互一致的。 注9：不希望出现冗余的可追溯性，但至少应存在给定的可追溯性路径之一。 | ||||||
MLE.1.BP6：沟通已商定的机器学习需求和对运行环境的影响。将已商定的机器学习需求和机器学习运行环境的影响分析结果与所有受影响方进行沟通。 | ||||||
MLE.1 机器学习需求分析 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 | 成果6 |
输出信息项 | ||||||
17-00 需求 | X | X | ||||
17-54 需求属性 | X | X | ||||
13-52 沟通证据 | X | |||||
13-51 一致性证据 | X | |||||
15-51 分析结果 | X | X | ||||
基本实践 | ||||||
BP1：指定机器学习需求 | X | |||||
BP2：结构化机器学习需求 | X | |||||
BP3：分析机器学习需求 | X | |||||
BP4：分析对机器学习运行环境的影响 | X | |||||
BP5：确保一致性并建立双向可追溯性 | X | |||||
BP6：沟通已商定的机器学习需求 | X | |||||
过程ID | |||||||
MLE.2 | |||||||
过程名称 | |||||||
机器学习架构 | |||||||
过程目的 | |||||||
目的是建立一个支持训练和部署的机器学习架构，该架构与机器学习需求一致，并根据定义的标准对机器学习架构进行评估。 | |||||||
过程成果 | |||||||
1) 开发了一个机器学习架构。 2) 确定超参数范围和初始值作为训练的基础。 3) 对机器学习架构元素进行评估。 4) 定义机器学习架构元素的接口。 5) 定义机器学习架构元素的资源消耗目标。 6) 在机器学习架构元素和机器学习需求之间建立一致性和双向可追溯性。 7) 就机器学习架构达成一致，并与所有受影响方进行了沟通。 | |||||||
基本实践 | |||||||
MLE.2.BP1: 开发机器学习架构。开发和记录机器学习架构，该架构指定了机器学习架构元素，包括机器学习模型的详细信息、预处理和后处理，以及创建、训练、测试和部署机器学习模型所需的超参数。 注1: 机器学习模型的必要细节可能包括层、激活函数和反向传播。机器学习模型的详细程度可能不需要涵盖像单个神经元这样的方面。 注2: 训练期间使用的机器学习模型和已部署的机器学习模型的细节可能有所不同。 | |||||||
MLE.2.BP2: 确定超参数范围和初始值。确定并记录作为训练基础的超参数范围和初始值。 | |||||||
MLE.2.BP3: 分析机器学习架构元素。定义分析机器学习架构元素的标准。根据定义的标准分析机器学习架构元素。 注3: 可信度和可解释性可能是分析机器学习架构元素的标准。 | |||||||
MLE.2.BP4: 定义机器学习架构元素的接口。确定并记录每个机器学习架构元素的内部和外部接口，包括其与相关软件组件的接口。 | |||||||
MLE.2.BP5: 为机器学习架构元素定义资源消耗目标。确定并记录训练和部署期间所有相关机器学习架构元素的资源消耗目标。 | |||||||
MLE.2.BP6: 确保一致性和建立双向可追溯性。确保机器学习架构元素和机器学习需求之间的一致性和双向可追溯性。 注4: 双向可追溯性支持一致性，并有助于对变更请求进行影响分析，以及验证覆盖范围的演示。仅可追溯性（例如链接的存在）并不一定意味着信息之间是相互一致的。 注5: 双向可追溯性应在机器学习架构元素的合理抽象级别上建立。 | |||||||
MLE.2.BP7: 沟通商定的机器学习架构。向所有受影响方通报商定的机器学习架构，包括机器学习模型的详细信息和初始超参数值。 | |||||||
MLE.2 机器学习架构 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 | 成果6 | 成果7 |
输出信息项 | |||||||
04-51 机器学习架构 | X | X | X | X | X | ||
13-52 沟通证据 | X | ||||||
13-51 一致性证据 | X | ||||||
01-54 超参数 | X | X | |||||
15-51 分析结果 | X | X | |||||
基本实践 | |||||||
BP1: 开发机器学习架构 | X | ||||||
BP2: 确定超参数范围和初始值 | X | ||||||
BP3: 评估机器学习架构元素 | X | ||||||
BP4: 定义机器学习架构元素的接口 | X | ||||||
BP5: 为机器学习架构元素定义资源消耗目标 | X | ||||||
BP6: 确保一致性和建立双向可追溯性 | X | ||||||
BP7: 沟通商定的机器学习架构 | X | ||||||
过程ID | |||||
MLE.3 | |||||
过程名称 | |||||
机器学习训练 | |||||
过程目的 | |||||
优化ML模型以满足定义的ML需求。 | |||||
过程成果 | |||||
1) 指定了ML训练和验证方法。 2) 创建了用于ML训练和ML验证的数据集。 3) 优化了ML模型（包括超参数值），以满足定义的ML需求。 4) 在ML训练和验证数据集与ML数据需求之间建立了一致性和双向可追溯性。 5) 总结了优化结果，并就训练后的ML模型与所有受影响方达成了一致并进行了沟通。 | |||||
基本实践 | |||||
MLE.3.BP1：指定ML训练和验证方法。支持ML模型的训练和验证以满足定义的ML需求的方法。ML训练和验证方法包括： l 训练和验证的进入和退出标准， l 超参数调整/优化的方法， l 数据集创建和修改的方法，以及 l 训练和验证环境 注1：ML训练和验证方法可能包括随机丢弃和其他鲁棒性方法。 注2：ML验证是在机器学习训练（MLE.3）期间对超参数的优化。 注3：训练环境应反映已部署模型的环境。 | |||||
MLE.3.BP2：创建ML训练和验证数据集。从SUP.11提供的ML数据集中选择数据，并根据指定的ML训练和验证方法将它们分配给训练和验证ML模型的数据集。 注4：根据ML需求，ML训练和验证数据集可能包括极端情况、意外情况和正常情况。 注5：在某些情况下，可能不需要为训练和验证分开的数据集（例如，k折交叉验证，无需优化超参数）。 | |||||
MLE.3.BP3：创建和优化ML模型。根据ML架构创建ML模型，并使用根据ML训练和验证方法确定的ML训练和验证数据集对其进行训练，以满足定义的ML需求和训练及验证退出标准。 | |||||
MLE.3.BP4：确保一致性并建立双向可追溯性。确保ML训练和验证数据集与ML数据需求之间的一致性，并建立双向可追溯性。 注6：双向可追溯性支持一致性并促进变更请求的影响分析。仅可追溯性（例如，链接的存在）并不一定意味着信息之间相互一致。 | |||||
MLE.3.BP5：总结和沟通商定的训练后的ML模型。总结优化结果，并将商定的训练后的ML模型通知所有受影响方。 | |||||
MLE.3 机器学习训练 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 |
输出信息项 | |||||
08-65 ML训练和验证方法 | X | ||||
03-51 ML数据集 | X | ||||
01-53 训练后的ML模型 | X | ||||
01-54 超参数 | X | ||||
13-51 一致性证据 | X | ||||
13-52 沟通证据 | X | ||||
基本实践 | |||||
BP1：指定ML训练和验证方法 | X | ||||
BP2：创建ML训练和验证数据集 | X | ||||
BP3：创建和优化ML模型 | X | ||||
BP4：确保一致性并建立双向可追溯性 | X | ||||
BP5：总结和沟通商定的训练后的ML模型 | X | ||||
过程ID | ||||||
MLE.4 | ||||||
过程名称 | ||||||
机器学习模型测试 | ||||||
过程目的 | ||||||
确保训练后的机器学习模型和部署的机器学习模型符合机器学习要求。 | ||||||
过程成果 | ||||||
1) 定义机器学习测试方法。 2) 创建机器学习测试数据集。 3) 测试训练后的机器学习模型。 4) 从训练后的机器学习模型中派生出部署的机器学习模型并进行测试。 5) 在机器学习测试方法和机器学习要求之间，以及机器学习测试数据集和机器学习数据要求之间建立了一致性和双向可追溯性；在机器学习测试方法和机器学习测试结果之间建立双向可追溯性。 6) 总结机器学习模型测试的结果，并与所有受影响方就部署的机器学习模型进行沟通。 | ||||||
基本实践 | ||||||
MLE.4.BP1：指定机器学习测试方法。指定一种适合提供证据的机器学习测试方法，以证明训练后的机器学习模型和部署的机器学习模型符合机器学习要求。机器学习测试方法包括： l 由机器学习要求定义的具有数据特征分布（例如，性别、天气条件、运行设计域内的街道条件）的机器学习测试场景， l 机器学习测试数据集中每个机器学习测试场景的分布和频率， l 每个测试数据的预期测试结果， l 测试的进入和退出标准， l 数据集创建和修改的方法，以及 l 所需的测试基础设施和环境设置。 注1：每个测试数据的预期测试结果可能需要对测试数据进行标记，以支持将机器学习模型的输出与预期输出进行比较。 注2：测试数据是机器学习模型处理的最小数据量，仅产生一个输出。例如，照片处理中的一张图像或语音识别中的一个音频序列。 注3：数据特征是可能在运行设计域中有不同表达的数据的一个属性。例如，天气条件可能包含晴朗、有雾或下雨等表达。 注4：机器学习测试场景是所有定义的数据特征表达的组合。例如，天气条件=晴朗，街道条件=碎石路。 | ||||||
MLE.4.BP2：创建机器学习测试数据集。根据机器学习测试方法，从SUP.11提供的机器学习数据集中创建测试训练后的机器学习模型和部署的机器学习模型所需的机器学习测试数据集。机器学习测试数据集不得用于训练。 注5：训练后的机器学习模型的机器学习测试数据集可能与部署的机器学习模型的测试数据集不同。 注6：可能需要使用额外的数据集来满足特殊目的，如保证安全性、公平性和稳健性。 | ||||||
MLE.4.BP3：测试训练后的机器学习模型。使用创建的机器学习测试数据集，根据机器学习测试方法测试训练后的机器学习模型。记录和评估机器学习测试结果。 注7：测试日志的评估可能包括对失败测试数据的模式分析，以支持例如可信度的提升。 | ||||||
MLE.4.BP4：派生出部署的机器学习模型。根据机器学习架构，从训练后的机器学习模型中派生出部署的机器学习模型。部署的机器学习模型应用于测试和交付给软件集成。 注8：部署的机器学习模型将集成到目标系统中，并可能与训练后的机器学习模型有所不同，后者通常需要强大的硬件并使用解释性语言。 | ||||||
MLE4.BP5：测试部署的机器学习模型。使用创建的机器学习测试数据集，根据机器学习测试方法测试部署的机器学习模型。记录和评估机器学习测试结果。 | ||||||
MLE.4.BP6：确保一致性并建立双向可追溯性。确保机器学习测试方法与机器学习要求之间，以及机器学习测试数据集与机器学习数据要求之间的一致性和双向可追溯性；在机器学习测试方法和机器学习测试结果之间建立双向可追溯性。 注9：双向可追溯性支持一致性，并有助于对变更请求进行影响分析，以及验证覆盖率的展示。仅存在链接等可追溯性并不一定意味着信息之间是一致的。 | ||||||
MLE.4.BP7：总结并沟通结果。总结机器学习模型的机器学习测试结果。向所有受影响方通知商定的结果和部署的机器学习模型。 | ||||||
MLE.4 机器学习模型测试 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 | 成果6 |
输出信息项 | ||||||
08-64 机器学习测试方法 | X | |||||
03-51 机器学习数据集 | X | |||||
13-50 机器学习测试结果 | X | X | ||||
11-50 部署的机器学习模型 | X | |||||
13-51 一致性证据 | X | |||||
13-52 沟通证据 | X | |||||
基本实践 | ||||||
BP1：指定机器学习测试方法 | X | |||||
BP2：创建机器学习测试数据集 | X | |||||
BP3：测试训练后的机器学习模型 | X | |||||
BP4：派生出部署的机器学习模型 | X | |||||
BP5：测试部署的机器学习模型 | X | |||||
BP6：确保一致性并建立双向可追溯性 | X | |||||
BP7：总结和沟通结果 | X | |||||
过程ID | |||||||
HWE.1 | |||||||
过程名称 | |||||||
硬件需求分析 | |||||||
过程目的 | |||||||
目的是建立一套符合系统要求和系统体系结构设计的、经过结构化分析的硬件需求集合。 | |||||||
过程成果 | |||||||
1）硬件需求已明确。 2）硬件需求已结构化并确定优先级。 3）对硬件需求的正确性和技术可行性进行分析。 4）分析硬件需求对操作环境的影响。 5）在硬件需求和系统需求之间建立一致性和双向可追溯性。 6）在硬件需求和系统体系结构设计之间建立一致性和双向可追溯性。 7）硬件需求已得到所有受影响方的同意并已沟通。 | |||||||
基本实践 | |||||||
HWE.1.BP1: 明确硬件需求。使用系统需求和系统架构（包括接口定义）来根据已定义的需求特性来识别和记录硬件的功能性和非功能性需求。 注1: 需求特性在诸如ISO IEEE 29148、ISO/IEC IEEE 24765、ISO 26262-8:2018或INCOSE的《需求编写指南》等标准中定义。 注2: 上述标准共享的定义好的需求特性示例包括可验证性（即需求文本中固有的验证标准）、明确性/可理解性、独立于设计和实现，以及不与其他任何需求相矛盾。 注3: 在仅进行硬件开发的情况下，系统需求和系统架构指的是给定的运行环境。在这种情况下，利益相关方的需求可以作为确定硬件所需功能和性能的基础。 注4: 硬件-软件接口（HSI）定义将软件置于上下文中，因此是系统设计层面的接口决策。如果存在这样的HSI，则它可以为硬件需求提供输入。 | |||||||
HWE.1.BP2: 结构化硬件需求。对硬件需求进行结构化和优先级排序。 注5: 结构化标准的示例可以是分组（例如，按功能）或变体识别。 注6: 优先级排序可以根据项目或利益相关者的需求进行，例如通过定义发布范围。参见SPL.2.BP1。 | |||||||
HWE.1.BP3: 分析硬件需求。分析指定的硬件需求，包括它们之间的相互依赖关系，以确保正确性、技术可行性，并支持项目管理关于项目估算的方面。 注7: 关于项目可行性，参见MAN.3.BP3；关于项目估算，参见MAN.3.BP5。 注8: 技术可行性的分析可以基于给定的硬件设计（例如平台）或原型开发进行。 | |||||||
HWE.1.BP4: 分析对运行环境的影响。确定指定硬件与运行环境其他元素之间的接口。分析硬件需求对这些接口和运行环境的影响。 | |||||||
HWE.1.BP5: 确保一致性并建立双向可追溯性。确保硬件需求与系统架构之间的一致性和可追溯性。确保硬件需求与系统需求之间的一致性和可追溯性。 注9: 不打算进行冗余的可追溯性。 注10: 可能存在硬件设计无法追溯到的非功能性硬件需求。例如开发过程需求。这些需求仍然需要进行验证。 注11: 双向可追溯性支持一致性，便于分析变更请求的影响，以及展示验证覆盖率。仅可追溯性（例如链接的存在）并不一定意味着信息之间是一致的。 注12: 在仅进行硬件开发的情况下，系统需求和系统架构指的是给定的运行环境。在这种情况下，可以确保利益相关者的需求和硬件需求之间的一致性和双向可追溯性。 | |||||||
HWE.1.BP6: 沟通商定的硬件需求和对运行环境的影响。向所有受影响方沟通商定的硬件需求和对运行环境影响的分析结果。 | |||||||
HWE.1 硬件需求分析 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 | 成果6 | 成果7 |
输出信息项 | |||||||
13-52 沟通证据 | X | ||||||
13-51 一致性证据 | X | X | |||||
17-00 需求 | X | X | X | ||||
17-54 需求属性 | X | ||||||
15-51 分析结果 | X | X | |||||
基本实践 | |||||||
BP1: 明确硬件需求 | X | ||||||
BP2: 结构化硬件需求 | X | ||||||
BP3: 分析硬件需求 | X | ||||||
BP4: 分析对运行环境的影响 | X | ||||||
BP5: 确保一致性并建立双向可追溯性 | X | X | |||||
BP6: 沟通商定的硬件需求 | X | ||||||
过程ID | ||||||
HWE.2 | ||||||
过程名称 | ||||||
硬件设计 | ||||||
过程目的 | ||||||
本过程的目的是提供一个经过分析的设计（包括动态方面），该设计与硬件需求保持一致，适合制造，并能导出与生产相关的数据。 | ||||||
过程成果 | ||||||
1) 开发一个硬件架构和硬件详细设计，确定硬件的组成元素，描述它们的行为和接口，以及硬件元素之间的动态交互。 2) 对硬件架构和硬件详细设计进行分析，并确定了特殊特性。 3) 在硬件需求和硬件设计之间建立一致性和双向可追溯性。 4) 从硬件详细设计中导出硬件生产数据，并与所有受影响方进行沟通。 5) 从硬件详细设计中导出生产测试信息，并与所有受影响方进行沟通。 6) 就硬件架构、硬件详细设计和特殊特性达成一致，并与所有受影响方进行沟通。 | ||||||
基本实践 | ||||||
HWE.2.BP1: 指定硬件架构。开发能够识别硬件组件的硬件架构。记录所定义硬件架构的基本原理。 注1：硬件架构中反映的方面示例包括接地概念、供电概念、EMC概念。 注2：设计原理的示例可以分别通过重用标准硬件、平台或产品线，或通过自制或外购决策，或以进化的方式找到。 | ||||||
HWE.2.BP2: 指定硬件详细设计。基于硬件架构中识别的组件，指定预期硬件变体的详细设计描述和原理图，包括硬件元素之间的接口。导出硬件布局、硬件材料清单和生产数据。 注3：硬件材料清单中硬件部件及其供应商的识别可能受到预定义存储库的限制（另见IATF 16949:2016，第8.4.1.2条）。 注4：硬件详细设计可能受到诸如市场上硬件部件的可用性、硬件设计规则、布局规则、爬电距离和电气间隙、HW部件符合AEC-Q、REACH等行业标准等限制。 | ||||||
HWE.2.BP3: 指定动态方面。评估和记录相关硬件元素的动态行为以及它们之间的相互作用。 注5：并非所有硬件元素都有需要描述的动态行为。 | ||||||
HWE.2.BP4: 分析硬件架构和硬件详细设计。从相关技术方面分析硬件架构和硬件详细设计，并就项目估算为项目管理提供支持。确定特殊特性。 注6：技术方面的示例包括生产可制造性、可重用的现有硬件组件的适用性，或硬件元素的可用性。 注7：适合分析技术方面的方法示例包括模拟、计算、定量或定性分析，如FMEA。 HWE.2.BP5: 确保一致性并建立双向可追溯性。确保硬件元素和硬件需求之间的一致性，并建立可追溯性。确保硬件详细设计与硬件架构组件之间的一致性，并建立可追溯性。 注8：可能存在硬件设计无法追溯到的非功能性硬件需求。示例是开发过程需求。这些需求仍然需要进行验证。 注9：双向可追溯性进一步支持一致性，并有助于分析变更请求的影响，以及展示验证覆盖范围。仅可追溯性（例如链接的存在）并不一定意味着信息是相互一致的。 | ||||||
HWE.2.BP6: 沟通商定的硬件架构和硬件详细设计。向所有受影响方沟通商定的硬件架构和硬件详细设计，包括特殊特性和相关生产数据。 | ||||||
HWE.2 硬件设计 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 | 成果6 |
输出信息项 | ||||||
04-52 硬件架构 | X | |||||
04-53 硬件详细设计 | X | |||||
15-51 分析结果 | X | |||||
13-51 一致性证据 | X | |||||
17-57 特殊特性 | X | |||||
13-52 沟通证据 | X | |||||
04-54 硬件原理图 | X | X | X | |||
14-54 硬件材料清单 | X | X | X | |||
04-55 硬件布局 | X | X | X | |||
03-54 硬件生产数据 | X | X | X | |||
04-56 硬件元素接口 | X | |||||
基本实践 | ||||||
BP1: 指定硬件架构 | X | X | X | |||
BP2: 指定硬件详细设计 | X | X | X | |||
BP3: 指定动态方面 | X | |||||
BP4: 分析硬件架构和硬件详细设计 | X | |||||
BP5: 确保一致性并建立双向可追溯性 | X | |||||
BP7: 沟通商定的硬件架构和硬件详细设计 | X | X | X | |||
过程ID | ||||||
HWE.3 | ||||||
过程名称 | ||||||
硬件设计验证 | ||||||
过程目的 | ||||||
确保符合生产数据的硬件得到验证，以提供符合硬件设计的证据。 | ||||||
过程成果 | ||||||
1) 针对硬件与硬件设计之间的验证，指定了验证措施，包括硬件元素之间的接口和动态方面。 2) 根据发布范围考虑标准，选择验证措施，包括回归验证的标准。 3) 使用选定的验证措施对符合生产数据的样件进行验证，并记录验证结果。 4) 在硬件元素和验证措施之间建立一致性和双向可追溯性。 5) 在验证措施和验证结果之间建立双向可追溯性。 6) 总结验证结果并与所有受影响方进行沟通。 | ||||||
基本实践 | ||||||
HWE.3.BP1: 指定针对硬件设计的验证措施。 指定适合的验证措施，以提供硬件符合硬件设计及其动态方面的证据。这包括： l 验证措施的技术； l 验证措施的通过/失败标准； l 验证措施的进入和退出标准的定义； l 验证措施的必要顺序； l 所需的验证基础设施和环境设置。 注1: 验证措施可能关注的示例包括接口硬件元素之间正确信号流的及时性和时间依赖性，以及硬件组件之间的交互。 注2: 测量点可用于硬件元素的逐步测试。 | ||||||
HWE.3.BP2: 确保使用符合要求的样件。确保用于验证硬件设计的样件符合相应的生产数据，包括特殊特性。确保偏差得到记录并且不会改变验证结果。 注3: 符合性的示例包括样件报告、目视检查报告、ICT报告。 | ||||||
HWE.3.BP3: 选择验证措施。记录考虑选择标准（包括回归标准）的验证措施的选择。根据发布范围，记录的验证措施选择应具有足够的覆盖范围。 注4: 选择标准的示例可以是需求的优先级、由于硬件设计更改而需要的回归，或交付的硬件版本的预期用途（例如，试验台、试验场、公共道路等）。 | ||||||
HWE.3.BP4: 验证硬件设计。使用选定的验证措施验证硬件设计。记录验证结果，包括通过/失败状态和相应的验证措施输出数据。 注5: 见SUP.9处理不符合项。 | ||||||
HWE.3.BP5: 确保一致性并建立双向可追溯性。确保硬件元素和验证措施之间的一致性并建立双向可追溯性。在验证措施和验证结果之间建立双向可追溯性。 注6: 双向可追溯性支持一致性，并有助于分析变更请求的影响，以及演示验证覆盖范围。仅可追溯性（例如链接的存在）并不一定意味着信息之间相互一致。 | ||||||
HWE.3.BP6: 总结并沟通结果。总结验证结果并与所有受影响方进行沟通。 注7: 在摘要中提供测试用例执行的所有必要信息，使其他方能够判断后果。 | ||||||
HWE.3 硬件设计验证 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 | 成果6 |
输出信息项 | ||||||
08-60 验证措施 | X | |||||
03-50 验证措施数据 | X | |||||
08-58 验证措施选择集 | X | |||||
15-52 验证结果 | X | |||||
13-51 一致性证据 | X | X | ||||
13-52 沟通证据 | X | |||||
基本实践 | ||||||
BP1: 指定针对硬件设计的验证措施 | X | |||||
BP2: 确保使用符合要求的样件 | X | |||||
BP3: 选择验证措施 | X | |||||
BP4: 验证硬件设计 | X | |||||
BP5: 确保一致性并建立双向可追溯性 | X | X | ||||
BP6: 总结并沟通结果 | X | |||||
过程ID | ||||||
HWE.4 | ||||||
过程名称 | ||||||
硬件需求验证 | ||||||
过程目的 | ||||||
该过程的目的是确保整个硬件经过验证，与硬件需求保持一致。 | ||||||
过程成果 | ||||||
1) 针对硬件需求的硬件验证措施已规定。 2) 选择验证措施时考虑了包括回归验证标准在内的各项标准。 3) 使用选定的验证措施（如果适用，则为符合生产数据的样件）进行验证，并记录验证结果。 4) 在验证措施和硬件需求之间建立一致性和双向可追溯性。 5) 在验证措施和验证结果之间建立双向可追溯性。 6) 汇总验证结果并与所有受影响方进行沟通。 | ||||||
基本实践 | ||||||
HWE.4.BP1: 规定针对硬件需求的验证措施。规定验证措施以提供证据证明符合硬件需求。这包括： l 验证措施的技术； l 验证措施的通过/失败标准； l 验证措施的进入和退出标准定义； l 验证措施的必要顺序；以及 l 所需的验证基础设施和环境设置。 注1：验证措施可能涵盖热、环境、稳健性/寿命和EMC等方面。 | ||||||
HWE.4.BP2: 确保使用符合要求的样件。确保用于验证硬件需求的样件符合由硬件设计提供的相应生产数据，包括特殊特性。 注2：符合性的示例包括样件报告、目视检查记录、ICT报告。 | ||||||
HWE.4.BP3: 选择验证措施。记录考虑选择标准（包括回归标准）的验证措施选择情况。根据发布范围，记录的验证措施选择应具有足够的覆盖范围。 注3：选择标准的示例可以是需求的优先级、由于硬件需求变更而需要进行回归的需求，或所交付的硬件版本的预期用途（例如，试验台、试验场、公共道路等）。 | ||||||
HWE.4.BP4: 验证符合要求的硬件样件。使用选定的验证措施验证符合要求的硬件样件。记录验证结果，包括通过/失败状态和相应的验证措施输出数据。 注4：请参阅SUP.9以了解不符合项的处理方法。 | ||||||
HWE.4.BP5: 确保一致性并建立双向可追溯性。确保硬件需求和验证措施之间的一致性。在硬件需求和验证措施之间建立双向可追溯性。在验证措施和验证结果之间建立双向可追溯性。 注5：双向可追溯性支持一致性，并有助于分析变更请求的影响以及展示验证覆盖范围。仅可追溯性（例如链接的存在）并不一定意味着信息之间相互一致。 | ||||||
HWE.4.BP6: 汇总并沟通结果。汇总验证结果并与所有受影响方进行沟通。 注6：在摘要中提供测试用例执行的所有必要信息，使其他方能够判断后果。 | ||||||
HWE.4 硬件需求验证 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 | 成果6 |
输出信息项 | ||||||
08-60 验证措施 | X | |||||
03-50 验证措施数据 | X | |||||
08-58 验证措施选择集 | X | |||||
15-52 验证结果 | X | |||||
13-51 一致性证据 | X | X | ||||
13-52 沟通证据 | X | |||||
基本实践 | ||||||
BP1: 规定针对硬件需求的验证措施 | X | |||||
BP2: 确保使用符合要求的样件 | X | |||||
BP3: 选择验证措施 | X | |||||
BP4: 验证硬件 | X | |||||
BP5: 确保一致性并建立双向可追溯性 | X | X | ||||
BP6: 汇总并沟通结果 | X | |||||
过程ID | ||||||
SUP.1 | ||||||
过程名称 | ||||||
质量保证 | ||||||
过程目的 | ||||||
质量保证过程的目的是提供独立且客观的保证，确保工作产品和过程符合定义的标准，并解决和预防不符合项。 | ||||||
过程成果 | ||||||
1) 质量保证是独立且客观地执行的，没有利益冲突。 2) 定义工作产品和过程性能的质量标准。 3) 验证工作产品和过程性能是否符合定义的标准和目标，并记录下来与相关方沟通。 4) 跟踪、解决并进一步预防不符合项。 5) 将不符合项升级到适当的管理层级。 6) 管理层确保升级的不符合项得到解决。 | ||||||
基本实践 | ||||||
SUP.1.BP1：确保质量保证的独立性。确保质量保证是独立且客观地执行的，没有利益冲突。 注1：评估独立性的可能输入可能包括分配给财务和/或组织结构的责任，以及受质量保证影响的过程的责任（无自我监控）。 | ||||||
SUP.1.BP2：定义质量保证的标准。为工作产品以及过程任务及其性能定义质量标准。 注2：质量标准可以考虑内部和外部输入，如客户要求、标准、里程碑等。 | ||||||
SUP.1.BP3：确保工作产品的质量。根据质量标准确定受质量保证的工作产品。执行适当的活动，根据定义的质量标准评估工作产品，并记录结果。 注3：质量保证活动可能包括审查、问题分析和经验教训，以改进工作产品以供将来使用。 | ||||||
SUP.1.BP4：确保过程活动的质量。根据质量标准确定受质量保证的过程。执行适当的活动，根据定义的质量标准和相关的目标值评估过程，并记录结果。 注4：质量保证活动可能包括过程评估、问题分析、定期检查方法、工具和遵守定义的过程，以及考虑经验教训。 | ||||||
SUP.1.BP5：总结和沟通质量保证活动和结果。定期向所有受影响方报告质量保证活动的性能、不符合项和趋势。 | ||||||
SUP.1.BP6：确保不符合项的解决。分析、跟踪、纠正、解决并进一步预防在质量保证活动中发现的不符合项。 注5：在工作产品中检测到的不符合项可能进入问题解决方案管理过程（SUP.9）。 注6：在过程定义或实施中检测到的不符合项可能进入过程改进过程（PIM.3）。 | ||||||
SUP.1.BP7：升级不符合项。将相关的不符合项升级到适当的管理层级和其他相关的利益相关方，以促进其解决。 注7：升级不符合项的决定可能基于标准，如解决延迟、紧急性和风险。 | ||||||
SUP.1 质量保证 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 | 成果6 |
输出信息项 | ||||||
16-50 组织结构 | X | X | ||||
18-52 升级路径 | X | X | ||||
18-07 质量标准 | X | X | X | |||
13-52 沟通证据 | X | X | X | |||
13-18 质量符合性证据 | X | X | ||||
13-19 审查证据 | X | X | ||||
14-02 纠正措施 | X | X | ||||
基本实践 | ||||||
BP1：确保质量保证的独立性 | X | |||||
BP2：定义质量保证的标准 | X | |||||
BP3：确保工作产品的质量 | X | X | ||||
BP4：确保过程活动的质量 | X | X | ||||
BP5：总结和沟通质量保证活动和结果 | X | X | X | |||
BP6：确保不符合项的解决 | X | X | ||||
BP7：升级不符合项 | X | X | ||||
过程ID | ||||||||
SUP.8 | ||||||||
过程名称 | ||||||||
配置管理 | ||||||||
过程目的 | ||||||||
配置管理过程的目的是建立和维护相关配置项和基线的完整性，并使它们对受影响方可用。 | ||||||||
过程成果 | ||||||||
1) 定义和应用配置项的选择标准。 2) 定义配置项属性。 3) 建立配置管理。 4) 控制修改。 5) 应用基线。 6) 记录并报告配置项的状态。 7) 确保基线的完整性和一致性。 8) 验证备份和恢复机制的可用性。 | ||||||||
基本实践 | ||||||||
SUP.8.BP1：识别配置项。定义用于识别要接受配置管理的相关工作产品的选择标准。根据定义的选择标准识别和记录配置项。 注1：配置项代表作为单个实体接受配置管理的工作产品或工作产品组。 注2：配置项在复杂性、大小和类型上可能有所不同，范围从包括所有系统、硬件和软件文档在内的整个系统到一个元素或文档。 注3：选择标准可应用于单个工作产品或一组工作产品。 | ||||||||
SUP.8.BP2：定义配置项属性。定义修改和控制配置项所需的必要属性。 注4：可以为单个配置项或一组配置项定义配置项属性。 注5：配置项属性可能包括状态模型（例如，处理中、已测试、已发布等）、存储位置、访问权限等。 注6：属性的应用可以通过配置项的属性来实现。 | ||||||||
SUP.8.BP3：建立配置管理。为已识别的配置项（包括配置项属性）建立配置管理机制，包括控制配置项并行修改的机制。 注7：这可能包括针对不同配置项类型的特定机制，例如分支和合并管理或检出控制。 | ||||||||
SUP.8.BP4：控制修改。使用配置管理机制控制修改。 注8：这可能包括对配置项应用定义的状态模型。 | ||||||||
SUP.8.BP5：建立基线。为内部目的和外部产品交付定义和建立所有相关配置项的基线。 | ||||||||
SUP.8.BP6：总结和传达配置状态。记录、总结和向受影响方传达配置项和已建立基线的状态，以支持进度和状态的监控。 注9：基于定义的状态模型定期沟通配置状态支持项目管理、质量活动和专门的项目阶段，如软件集成。 | ||||||||
SUP.8.BP7：确保完整性和一致性。确保关于配置项的信息（包括配置项属性）是正确的和完整的。确保基线的完整性和一致性。 注10：基线的完整性和一致性意味着所有所需的配置项都已包含且一致，并具有所需的状态。这可用于支持例如项目门批准。 | ||||||||
SUP.8.BP8：验证备份和恢复机制的可用性。验证配置管理（包括受控配置项）的适当备份和恢复机制的可用性。在备份和恢复机制不足的情况下采取措施。 注11：备份和恢复机制可能由项目团队外部的组织单位定义和实施。这可能包括对相应程序或法规的引用。 | ||||||||
SUP.8 配置管理 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 | 成果6 | 成果7 | 成果8 |
输出信息项 | ||||||||
18-53 配置项选择标准 | X | |||||||
01-52 配置项列表 | X | X | X | |||||
16-03 配置管理系统 | X | X | X | |||||
13-08 基线 | X | X | ||||||
14-01 更改历史记录 | X | X | X | |||||
15-56 配置状态 | X | |||||||
13-51 一致性证据 | X | |||||||
06-52 备份和恢复 机制信息 | X | |||||||
基本实践 | ||||||||
BP1：识别配置项 | X | |||||||
BP2：定义配置项属性 | X | |||||||
BP3：建立配置管理 | X | X | ||||||
BP4：控制修改 | X | |||||||
BP5：建立基线 | X | |||||||
BP6：总结和传达配置状态 | X | |||||||
BP7：确保完整性和一致性 | X | |||||||
BP8：验证备份和恢复机制的可用性 | X | |||||||
过程ID | |||||
SUP.9 | |||||
过程名称 | |||||
问题解决管理 | |||||
过程目的 | |||||
问题解决管理过程的目的是确保问题被识别、记录、分析，并且问题的解决被管理和控制。 | |||||
过程成果 | |||||
1) 问题被唯一识别、记录和分类。 2) 问题被分析和评估以确定适当的解决方案。 3) 问题解决被启动。 4) 问题被追踪到关闭。 5) 包括所识别趋势的问题状态被报告给利益相关方。 | |||||
基本实践 | |||||
SUP.9.BP1: 识别和记录问题。每个问题都被唯一识别、描述和记录。为每个问题分配一个状态以便于追踪。提供支持信息以复现和诊断问题。 注1: 问题可能与产品、资源或方法等有关。 注2: 问题状态的示例值有“新”、“已解决”、“已关闭”等。 注3: 支持信息可能包括问题的来源、如何复现、环境信息、由谁检测等。 注4: 唯一标识支持对变更请求管理过程（SUP.10）所需做出的变更进行追踪。 | |||||
SUP.9.BP2: 确定问题的原因和影响。分析问题，确定其原因（包括如果存在的共同原因）和影响。让相关方参与。对问题进行分类。 注5: 问题分类（例如，轻微、中等、严重）可能基于严重性、关键性、紧急性等。 | |||||
SUP.9.BP3: 授权紧急解决行动。如果问题根据分类需要紧急解决，则获得立即行动的授权。 | |||||
SUP.9.BP4: 发出警报通知。如果根据分类，问题对其他系统或其他受影响方有高度影响，则需要相应地发出警报通知。 | |||||
SUP.9.BP5: 启动问题解决。根据分类启动适当的行动以长期解决问题，包括对这些行动进行审查或发起变更请求。这包括与适用的短期紧急解决行动进行同步和一致性。 | |||||
SUP.9.BP6: 追踪问题到关闭。追踪问题的状态到关闭，包括所有相关的变更请求。问题的关闭由相关利益相关方接受。 | |||||
SUP.9.BP7: 报告问题解决活动的状态。收集和分析问题解决管理数据，确定趋势，并启动相关行动。定期向相关利益相关方报告数据分析结果、所确定的趋势以及问题解决活动的状态。 注6: 收集的数据可能包含有关问题发生的位置、如何以及何时发现它们、它们的影响是什么等信息。 | |||||
SUP.9 问题解决管理 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 |
输出信息项 | |||||
13-07 问题 | X | X | X | X | |
15-55 问题分析证据 | X | ||||
15-12 问题状态 | X | ||||
基本实践 | |||||
BP1: 识别和记录问题 | X | X | |||
BP2: 确定问题的原因和影响 | X | X | |||
BP3: 授权紧急解决行动 | X | ||||
BP4: 发出警报通知 | X | ||||
BP5: 启动问题解决 | X | ||||
BP6: 追踪问题到关闭 | X | X | |||
BP7: 报告问题解决活动的状态 | X | ||||
过程ID | ||||||
SUP.10 | ||||||
过程名称 | ||||||
变更请求管理 | ||||||
过程目的 | ||||||
变更请求管理过程的目的是确保变更请求被记录、分析、追踪、批准和实施。 | ||||||
过程成果 | ||||||
1) 变更请求被记录和识别。 2) 变更请求被分析，识别与其他变更请求的依赖关系和联系，并估计其影响。 3) 变更请求在实施前获得批准，并据此确定优先级。 4) 在变更请求和受影响的工作产品之间建立双向可追溯性。 5) 变更请求的实施得到确认。 6) 变更请求被追踪到关闭，并将变更请求的状态通知给受影响方。 | ||||||
基本实践 | ||||||
SUP.10.BP1: 识别和记录变更请求。确定变更请求的应用范围。每个变更请求都被唯一识别、描述和记录，包括变更请求的发起人和原因。为每个变更请求分配一个状态以便于追踪。 注1: 变更请求可用于与产品、过程、方法等的变更相关的内容。 注2: 变更请求状态的示例值有“开放”、“调查中”、“已实施”等。 注3: 变更请求的处理在产品生命周期中可能会有所不同，例如在原型构建和系列开发期间。 | ||||||
SUP.10.BP2: 分析和评估变更请求。相关方根据分析标准对变更请求进行分析。确定受变更请求影响的工作产品以及与其他变更请求的依赖关系。评估变更请求的影响。 注4: 分析标准的示例包括：资源需求、调度问题、风险、收益等。 | ||||||
SUP.10.BP3: 在实施前批准变更请求。根据分析结果和资源可用性，对变更请求进行优先级排序并批准实施。 注5: 变更控制委员会（CCB）是用于批准变更请求的一种示例机制。 注6: 变更请求的优先级排序可以通过分配到版本来完成。 | ||||||
SUP.10.BP4: 建立双向可追溯性。在变更请求和受变更请求影响的工作产品之间建立双向可追溯性。如果变更请求是由问题发起的，则在变更请求和相应的问题报告之间建立双向可追溯性。 | ||||||
SUP.10.BP5: 确认变更请求的实施。在实施变更请求之前，由相关利益相关方确认其实施情况。 | ||||||
SUP.10.BP6: 追踪变更请求到关闭。变更请求被追踪到关闭。将变更请求的状态通知给所有受影响方。 注7: 通知受影响方的示例可以是每日站立会议或工具支持的工作流。 | ||||||
SUP.10 变更请求管理 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 | 成果6 |
输出信息项 | ||||||
18-57 变更分析标准 | X | |||||
13-16 变更请求 | X | X | X | X | X | |
13-51 一致性证据 | X | |||||
基本实践 | ||||||
BP1: 识别和记录变更请求 | X | |||||
BP2: 分析和评估变更请求 | X | |||||
BP3: 在实施前批准变更请求 | X | |||||
BP4: 建立双向可追溯性 | X | |||||
BP5: 确认变更请求的实施 | X | |||||
BP6: 追踪变更请求到关闭 | X | |||||
过程ID | |||||
SUP.11 | |||||
过程名称 | |||||
机器学习数据管理 | |||||
过程目的 | |||||
该过程的目的是定义和调整机器学习数据与机器学习数据需求，维护机器学习数据的完整性和质量，并使这些数据可供相关方使用。 | |||||
过程成果 | |||||
1) 建立包括机器学习数据生命周期在内的机器学习数据管理系统。 2) 开发包括机器学习数据质量标准在内的机器学习数据质量方法。 3) 处理收集的机器学习数据，以确保其与机器学习数据需求一致。 4) 根据定义的机器学习数据质量标准验证机器学习数据，并根据需要进行更新。 5) 与所有相关方就机器学习数据达成一致并进行沟通。 | |||||
基本实践 | |||||
SUP.11.BP1: 建立机器学习数据管理系统。建立一个机器学习数据管理系统，支持以下功能： l 机器学习数据管理活动 l 相关的机器学习数据来源 l 包括状态模型在内的机器学习数据生命周期 l 与相关方的接口 注1: 支持的机器学习数据管理活动可能包括数据收集、标记/注释和结构化。 | |||||
SUP.11.BP2: 开发机器学习数据质量方法。开发一种方法，确保基于定义的机器学习数据质量标准分析机器学习数据的质量，并执行活动以避免数据偏见。 注2: 机器学习数据质量标准的示例包括相关数据来源、标签的可靠性和一致性、相对于机器学习数据需求的完整性。 注3: 机器学习数据管理系统应支持机器学习数据质量方法的质量标准和活动。 注4: 要避免的偏见可能包括抽样偏见（例如，性别、年龄）和反馈循环偏见。 注5: 有关创建机器学习数据集的信息，请参阅MLE.3.BP2和MLE.4.BP2。 | |||||
SUP.11.BP3: 收集机器学习数据。确定原始数据的相关来源，并持续监控变化。根据机器学习数据需求收集原始数据。 注6: 机器学习数据的识别和收集可能是组织责任。 注7: 持续监控应包括运行设计域，并可能导致机器学习需求的变化。 | |||||
SUP.11.BP4: 处理机器学习数据。根据机器学习数据需求处理（注释、分析和结构化）原始数据。 | |||||
SUP.11.BP5: 确保机器学习数据的质量。根据机器学习数据质量方法执行活动，以确保机器学习数据符合定义的机器学习数据质量标准。 注8: 这些活动可能包括基于样本的审查或统计方法。 | |||||
SUP.11.BP6: 沟通已商定的处理过的机器学习数据。将所有已商定的处理过的机器学习数据通知相关方，并提供给这些相关方。 | |||||
机器学习数据管理 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 |
输出信息项 | |||||
16-52 机器学习数据管理系统 | X | ||||
19-50 机器学习数据质量方法 | X | ||||
03-53 机器学习数据 | X | X | |||
13-52 沟通证据 | X | ||||
基本实践 | |||||
BP1: 建立机器学习数据管理系统 | X | ||||
BP2: 开发机器学习数据质量方法 | X | ||||
BP3: 收集机器学习数据 | X | ||||
BP4: 处理机器学习数据 | X | ||||
BP5: 确保机器学习数据的质量 | X | ||||
BP6: 沟通已商定的处理过的机器学习数据 | X | ||||
过程ID | |||||||
MAN.3 | |||||||
过程名称 | |||||||
项目管理 | |||||||
过程目的 | |||||||
在项目的需求和约束条件下，确定和控制项目活动，建立项目开发产品所需的资源。 | |||||||
过程成果 | |||||||
1) 定义了项目的工作范围； 2) 评估了在可用资源和约束条件下实现项目目标的可行性； 3) 对完成工作所需的活动和资源进行了规模和估算； 4) 识别并监控了项目内部以及与其他项目和组织单位的接口； 5) 制定、实施和维护了项目执行计划； 6) 监控并报告了项目的进度； 7) 当项目目标未实现时进行了调整。 | |||||||
基本实践 | |||||||
MAN.3.BP1：定义工作范围。确定项目的目标、动机和边界。 | |||||||
MAN.3.BP2：定义项目生命周期。根据项目的范围、背景和复杂性定义项目生命周期。为相关里程碑定义发布范围。 注1：这可能包括将项目生命周期与客户的开发过程进行对齐。 | |||||||
MAN.3.BP3：评估项目的可行性。评估在时间、项目估算和可用资源方面实现项目目标的可行性。 注2：可行性的评估可能考虑项目的技术约束。 | |||||||
MAN.3.BP4：定义和监控工作包。根据项目定义的生命周期和估算，定义并监控工作包及其依赖关系。 注3：工作包的结构和大小支持适当的进度监控。 注4：工作包可以按工作分解结构进行组织。 | |||||||
MAN.3.BP5：定义和监控项目估算和资源。基于项目的目标、项目风险、动机和边界，定义并监控项目的努力和资源估算。 注5：必要资源的示例包括预算、人员、产品样品或基础设施。 注6：可以考虑项目风险（使用MAN.5）。 注7：估算和资源可能包括工程、管理和支持过程。 | |||||||
MAN.3.BP6：定义和监控所需的技能、知识和经验。根据项目估算和工作包，确定并监控项目所需的技能、知识和经验。 注8：可以通过培训、指导或辅导个人来解决与所需技能和知识的偏差 | |||||||
MAN.3.BP7：定义和监控项目接口和商定的承诺。识别并与受影响的利益相关者商定项目的接口，并监控商定的承诺。为未履行的承诺定义升级机制。 注9：受影响的利益相关者可能包括其他项目、组织单位、分包商和服务提供商。 | |||||||
MAN.3.BP8：定义和监控项目进度。为工作包分配资源，并安排项目的每项活动。根据进度监控活动的执行情况。 | |||||||
MAN.3.BP9：确保一致性。定期调整项目的估算、资源、技能、工作包及其依赖关系、计划、接口和承诺，以确保与工作范围的一致性。 注10：这可能包括考虑作为风险管理输入的关键依赖关系。 | |||||||
MAN.3.BP10：审查和报告项目的进度。定期审查和报告项目的状态以及工作包的完成情况与估算的努力和持续时间相比，向所有受影响方报告。防止已识别问题的再次发生。 注11：管理层可以定期执行项目审查。项目审查可能有助于确定最佳实践和经验教训。 注12：参见SUP.9以解决问题。 | |||||||
MAN.3 项目管理 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 | 成果6 | 成果7 |
输出信息项 | |||||||
08-53 工作范围 | X | ||||||
08-54 可行性分析 | X | X | |||||
14-10 工作包 | X | X | X | ||||
13-52 沟通证据 | X | X | |||||
13-16 变更请求 | X | ||||||
13-51 一致性证据 | X | X | |||||
14-02 纠正措施 | X | X | |||||
18-52 升级路径 | X | X | X | ||||
08-56 进度表 | X | X | X | ||||
14-50 利益相关者群 体列表 | X | ||||||
15-06 项目状态 | X | X | |||||
基本实践 | |||||||
BP1：定义工作范围 | X | ||||||
BP2：定义项目生命周期 | X | X | |||||
BP3：评估项目的可行性 | X | ||||||
BP4：定义和监控工作包 | X | X | X | X | |||
BP5：定义和监控项目估算和资源 | X | X | X | ||||
BP6：定义和监控所需的技能、知识和经验 | X | X | |||||
BP7：定义和监控项目接 口和商定的承诺 | X | X | X | ||||
BP8：定义和监控项目进度 | X | X | |||||
BP9：确保一致性 | X | X | X | X | |||
BP10：审查和报告项目进度 | X | X | |||||
过程ID | |||||
MAN.5 | |||||
过程名称 | |||||
风险管理 | |||||
过程目的 | |||||
本过程的目的是定期识别、分析、处理和监控与过程相关的风险和产品相关的风险。 | |||||
过程成果 | |||||
1) 识别并定期更新风险来源。 2) 在项目进行过程中，识别潜在的不良事件。 3) 分析风险，并确定处理这些风险的资源优先次序。 4) 定义、应用和评估风险措施，以确定风险状态的变化和风险处理活动的进展。 5) 根据风险的优先级、概率和后果或其他定义的风险阈值，采取适当的处理措施来纠正或避免风险的影响。 | |||||
基本实践 MAN.5.BP1: 识别风险来源。与受影响方一起识别和定期更新风险来源。 注1: 风险可能包括技术、经济和进度风险。 注2: 风险可能包括供应商的交付物和服务。 注3: 风险来源可能在整个项目生命周期内变化。 | |||||
MAN.5.BP2: 识别潜在的不良事件。在项目风险管理的范围内识别潜在的不良事件。 | |||||
MAN.5.BP3: 确定风险。确定不良事件的概率和严重性，以支持降低风险的优先级。 注4: 可以使用不同的方法来分析系统的技术风险，例如功能分析、模拟、FMEA、FTA等。 | |||||
MAN.5.BP4: 定义风险处理选项。为每个风险选择一个处理选项，以接受、减轻、避免或分享（转移）风险。 | |||||
MAN.5.BP5: 定义并执行风险处理活动。为风险处理选项定义并执行风险活动。 | |||||
MAN.5.BP6: 监控风险。定期重新评估与已识别的潜在不良事件相关的风险，以确定风险状态的变化并评估风险处理活动的进展。 注5: 高优先级的风险可能需要向更高级别的管理层报告并由其监控。 | |||||
MAN.5.BP7: 采取纠正措施。当风险处理活动无效时，采取适当的纠正措施。 注6: 纠正措施可能涉及重新评估风险、制定和实施新的缓解方案或调整现有方案。 | |||||
MAN.5 风险管理 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 |
输出信息项 | |||||
15-51 分析结果 | X | X | X | X | |
15-09 风险状态 | X | X | X | X | |
08-55 风险措施 | X | X | |||
14-02 纠正措施 | X | X | |||
基本实践 | |||||
BP1: 识别风险来源 | X | ||||
BP2: 识别潜在的不良事件 | X | ||||
BP3: 确定风险 | X | ||||
BP4: 定义风险处理选项 | X | X | |||
BP5: 定义并执行风险处理活动 | X | X | |||
BP6: 监控风险 | X | ||||
BP7: 采取纠正措施 | X | ||||
过程ID | |||||
MAN.6 | |||||
过程名称 | |||||
度量 | |||||
过程目的 | |||||
本过程的目的是收集和分析与组织及其项目内实施的开发结果和过程相关的数据，以支持对这些过程的有效管理。 | |||||
过程成果 | |||||
1) 识别出评估过程目标和工作产品成果达成情况所需的度量信息需求。 2) 根据信息需求，确定和/或开发一套适当的度量指标。 3) 确定并执行度量活动。 4) 收集、存储、分析所需的度量指标，并对结果进行解释。 5) 使用度量指标来支持决策，并为沟通提供客观依据。 | |||||
基本实践 | |||||
MAN.6.BP1: 识别信息需求。确定评估过程目标和工作产品成果达成情况所需的度量信息需求。 注1: 信息需求可能随时间而变化。因此，度量过程可以迭代方式使用。 | |||||
MAN.6.BP2: 确定度量指标。根据度量信息需求，确定和开发一套适当的度量指标。 注2: 度量指标可能与过程或开发结果相关。 | |||||
MAN.6.BP3: 收集并存储度量指标。收集和存储基本度量指标和派生度量指标，包括验证和理解度量指标所需的任何上下文信息。 注3: 在此过程中，基本度量指标是直接收集的度量，如“发现的缺陷数”或“代码行数”，而派生度量指标是两个或更多个度量指标的相互关系，如“每行代码发现的缺陷数”。 | |||||
MAN.6.BP4: 分析收集的度量指标。分析、解释和审查度量值，以支持决策制定。 | |||||
MAN.6.BP5: 沟通分析结果。将分析结果传达给所有受影响的相关方。 | |||||
MAN.6.BP6: 使用度量指标进行决策。在任何相关的决策过程中，提供并使用从收集的度量指标和分析结果中获得的信息。 | |||||
MAN.6 度量 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 |
输出信息项 | |||||
03-03 基准数据 | X | X | |||
03-04 客户满意度数据 | X | X | |||
03-06 过程性能信息 | X | X | |||
07-51 度量结果 | X | X | X | X | |
15-51 分析结果 | X | X | X | ||
基本实践 | |||||
BP1: 识别信息需求 | X | ||||
BP2: 确定度量指标 | X | X | |||
BP3: 收集并存储度量指标 | X | X | |||
BP4: 分析收集的度量指标 | X | X | |||
BP5: 沟通度量信息 | X | ||||
BP6: 使用度量指标进行决策 | X | ||||
过程ID | ||||||
PIM.3 | ||||||
过程名称 | ||||||
过程改进 | ||||||
过程目的 | ||||||
旨在通过所使用的过程持续提高组织的效能和效率，并确保这些过程与业务需求保持一致。 | ||||||
过程成果 | ||||||
1) 确立对提供资源以维持改进措施的承诺。 2) 将组织内部或外部环境产生的问题识别为改进机会，并证明其作为变更理由的合理性。 3) 对现有过程的当前状态进行分析。 4) 确定改进目标并进行优先排序，随后定义、记录并实施对过程的相应变更。 5) 监控、测量并确认过程实施的效果与已确定的改进目标的一致性。 6) 在组织内部沟通从改进中获得的知识。 | ||||||
基本实践 | ||||||
PIM.3.BP1: 建立承诺。为支持过程改进人员建立承诺，提供资源和进一步的使能因素以维持改进行动。 注1: 过程改进过程是一个通用过程，可用于所有级别（例如组织级别、过程级别、项目级别等），并可用于改进所有过程。 注2: 各级管理层的承诺可能支持过程改进。 注3: 改进措施的使能因素可能包括培训、方法、基础设施等。 | ||||||
PIM.3.BP2: 确定改进措施。通过分析过程性能确定问题，并导出具有合理变更理由的改进机会。 注4: 分析可能包括问题报告趋势分析（见SUP.9）、质量保证和验证结果与记录的分析（见SUP.1）、确认结果与记录，以及产品质量指标（如缺陷率）。 注5: 问题和改进建议可能由客户提出。 注6: 识别问题的来源可能包括：过程评估结果、审计、客户满意度报告、组织效能/效率的测量、质量成本。 | ||||||
PIM.3.BP3: 建立过程改进目标。分析现有过程的当前状态并确立改进目标。 注7: 过程的当前状态可能通过过程评估来确定。 | ||||||
PIM.3.BP4: 对改进排序。对改进目标和改进措施进行优先排序。 | ||||||
PIM.3.BP5: 定义过程改进措施。定义过程改进措施。 注8: 改进可以以递增的步骤进行记录。 | ||||||
PIM.3.BP6: 实施过程改进措施。将改进应用于过程中。根据需要更新过程文档并对人员进行培训。 注9: 过程应用可以通过建立政策、充足的过程基础设施、过程培训、过程指导和根据本地需求调整过程来支持。 注10: 在组织内部推广之前，改进可以进行试点。 | ||||||
PIM.3.BP7: 确认过程改进。监控和测量过程实施的效果，并确认已定义的改进目标的实现。 | ||||||
PIM.3.BP8: 沟通改进结果。将从改进中获得的知识和改进实施的进展与受影响的各方进行沟通。 | ||||||
PIM.3 过程改进 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 | 成果6 |
输出信息项 | ||||||
02-01 承诺/协议 | X | |||||
06-04 培训材料 | X | X | ||||
07-04 过程指标 | X | X | ||||
10-00 过程描述 | X | |||||
13-52 沟通证据 | X | |||||
13-16 变更请求 | X | |||||
15-51 分析结果 | X | X | X | X | ||
15-13 评估/审计报告 | X | X | ||||
15-16 改进机会 | X | X | X | |||
16-06 过程存储库 | X | |||||
基本实践 | ||||||
BP1: 建立承诺 | X | |||||
BP2: 确定改进措施 | X | X | ||||
BP3: 建立过程改进目标 | X | |||||
BP4: 对改进排序 | X | |||||
BP5: 定义过程改进措施 | X | |||||
BP6: 实施过程改进措施 | X | |||||
BP7: 确认过程改进 | X | |||||
BP8: 沟通改进结果 | X | |||||
过程ID | ||||||
REU.2 | ||||||
过程名称 | ||||||
可重用产品的管理 | ||||||
过程目的 | ||||||
本过程的目的是确保被重用的工作产品得到分析、验证，并针对其目标环境得到批准。 | ||||||
过程成果 | ||||||
1) 使用定义的标准选择可重用的产品。 2) 分析可重用产品的可移植性和互操作性。 3) 定义并沟通重用的限制。 4) 验证可重用的产品。 5) 向受影响的各方提供可重用的产品。 6) 与可重用产品的提供者建立沟通机制。 | ||||||
基本实践 | ||||||
REU.2.BP1: 选择可重用的产品。使用定义的标准选择要重用的产品。 注1: 可重用的产品可能是系统、硬件或软件组件、第三方组件或遗留组件。 | ||||||
REU.2.BP2: 分析产品的重用能力。分析指定的目标架构和要重用的产品，根据相关标准确定其在目标架构中的适用性。 注2: 标准的示例可以是需求合规性、产品在目标架构中的可验证性，或可移植性/互操作性。 | ||||||
REU.2.BP3: 定义重用的限制。定义并沟通要重用的产品的限制。 注3: 限制可能涉及操作环境的参数。 | ||||||
REU.2.BP4: 确保可重用产品的资格。提供证据表明可重用的产品符合交付物的预期用途。 注4: 资格可以通过验证证据来证明。 注5: 验证可能包括文档的适当性。 | ||||||
REU.2.BP5: 提供可重用的产品。向受影响的各方提供要重用的产品。 注6: 有关硬件、软件或系统组件的集成，请参阅HWE.3、SWE.5或SYS.4以获取更多信息。 | ||||||
REU.2.BP6: 沟通重用活动的有效性信息。建立与可重用产品的提供者沟通经验和技术成果的通知机制。 注7: 与可重用产品的提供者的沟通可能取决于该产品是否处于开发阶段。 | ||||||
REU.2 可重用产品的管理 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 | 成果6 |
输出信息项 | ||||||
04-02 领域架构 | X | X | ||||
12-03 重用候选者 | X | X | ||||
13-52 沟通证据 | X | |||||
15-07 重用分析证据 | X | X | ||||
13-53 资格证据 | X | |||||
基本实践 | ||||||
BP1: 选择可重用的产品 | X | |||||
BP2: 分析产品的重用能力 | X | |||||
BP3: 定义重用的限制 | X | |||||
BP4: 确保可重用产品的资格 | X | |||||
BP5: 提供可重用的产品 | X | |||||
BP6: 沟通重用活动的有效性信息 | X | |||||
为每个过程属性定义过程能力指标是度量框架的一个组成部分。过程能力指标，如通用实践和信息项，是支持判断相关过程属性实现程度的方法。
本章定义了度量框架[3.2]中为每个能力等级定义的通用实践和信息项，以及它们与过程属性的映射关系。
注：由于过程能力等级0没有定义的过程属性，因此没有定义通用实践和信息项。
过程能力等级 | 过程属性ID 过程属性名称 过程属性范围 过程成果 | 每个过程属性都具有一个唯一标识符和名称。提供过程属性范围说明，并定义过程成果。 |
过程属性实现指标 | 通用实践 | 针对过程属性的一组通用实践，提供为实现过程属性范围和完成过程成果而需执行活动的定义。 在过程结束时，总结通用实践的要点，以展示它们与过程属性成果之间的关系。 |
输出信息项 | 与实现过程属性范围和完成过程成果相关的输出信息项，在过程属性部分的结尾进行总结，以展示它们与过程成果之间的关系。 注：有关每个信息项的特性，请参阅附录B。 |
表22—过程描述模板
该过程未实施或未能实现其过程目的。在这一等级，几乎没有或根本没有证据表明该过程目的已得到系统性实现。
已实施的过程实现了其过程目的。以下过程属性表明了这一等级的实现。
过程属性ID | |
PA 1.1 | |
过程属性名称 | |
过程实施过程属性 | |
过程属性范围 | |
过程实施过程属性是衡量过程目的实现程度的指标。 | |
过程属性成果 | |
过程实现其定义的结果。 | |
通用实践 | |
GP 1.1.1 实现过程成果 实现基本实践的意图。 产生证明过程成果的工作产品。 | |
PA 1.1过程实施过程属性 | 成果1 |
输出信息项 | |
如第4章所述的过程特定信息项 | X |
通用实践 | |
GP 1.1.1 实现过程成果 | X |
以下过程属性，连同先前定义的过程属性，共同表明了这一等级的实现。
过程属性ID | ||||||||
PA 2.1 | ||||||||
过程属性名称 | ||||||||
过程实施管理过程属性 | ||||||||
过程属性范围 | ||||||||
过程实施管理过程属性是衡量过程实施被管理程度的指标。 | ||||||||
过程属性成果 | ||||||||
1) 基于确定的目标定义过程的执行策略。 2) 规划过程的执行。 3) 监控过程的执行并进行调整以满足规划。 4) 确定执行过程所需的人力资源，包括责任和权限。 5) 确定所需的物理和物质资源。 6) 为执行过程的人员准备执行其职责。 7) 确定、提供、分配和使用执行过程所需的物理和物质资源。 8) 管理相关方之间的接口，以确保有效的沟通和责任分配。 | ||||||||
通用实践 | ||||||||
GP 2.1.1：确定目标并定义过程的执行策略。 确定过程活动的范围，包括过程实施的管理和工作产品的管理。 确定要实现的相应结果。 确定过程实施目标及相关标准。 注1：预算目标和向客户交付的日期、测试覆盖范围和过程提前期的目标是过程实施目标的示例。 注2：实施目标是规划和监控的基础。 在确定实施目标时，考虑假设和约束条件。 确定过程实施的方法和方法论。 注3：过程实施策略不一定需要为每个过程专门编写文档。适用于多个过程的元素可以联合编写文档，例如作为共同项目手册的一部分或在联合测试策略中。 | ||||||||
GP 2.1.2：规划过程的执行。 根据定义的目标、标准和策略建立过程的执行规划。 定义过程活动和工作包。 使用适当的方法确定工作包的估算。 注4：定义时间表和里程碑。 | ||||||||
GP 2.1.3：确定资源需求。 基于规划确定过程执行所需的人力资源数量以及经验、知识和技能需求。 基于规划确定所需的物理和物质资源。 注5：物理和物质资源可能包括设备、实验室、材料、工具、许可证等。 确定执行过程以及管理工作产品所需的责任和权限。 注6：责任和权限的定义不一定需要正式的角色描述。 | ||||||||
GP 2.1.4：确定并提供资源。 根据确定的需求确定执行管理过程的人员，并进行分配。 使执行和管理过程的人员具备执行其职责的资格。 注7：人员的资格可能包括培训、指导或辅导。 根据确定的需求确定、提供、分配和使用执行过程所需的其他资源。 | ||||||||
GP 2.1.5：监控并调整过程的执行。 监控过程实施以识别与规划的偏差。 在出现与规划的偏差时采取适当的行动。 根据需要调整规划。 | ||||||||
GP 2.1.6：管理相关方之间的接口。 确定参与过程执行的个人和团队，包括所需的外部相关方。 向相关个人或相关方分配责任。 确定相关方之间的沟通机制。 建立和维护相关方之间的有效沟通。 | ||||||||
PA 2.1 过程实施管理 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 | 成果6 | 成果7 | 成果8 |
输出信息项 | ||||||||
19-01 过程实施策略 | X | |||||||
18-58 过程实施目标 | X | |||||||
14-10 工作包 | X | |||||||
08-56 时间表 | X | X | ||||||
13-10 进度状态 | X | |||||||
17-55 资源需求 | X | X | ||||||
08-61 资源分配 | X | X | ||||||
08-62 沟通矩阵 | X | |||||||
13-52 沟通证据 | X | |||||||
通用实践 | ||||||||
GP 2.1.1：确定目标并定义过程的执行策略 | X | |||||||
GP 2.1.2：规划过程的执行 | X | |||||||
GP 2.1.3：确定资源需求 | X | X | ||||||
GP 2.1.4: 识别和提供可用资源 | X | X | ||||||
GP 2.1.5: 监控和调整过程的性能 | X | |||||||
GP 2.1.6: 管理相关方之间的接口 | X | |||||||
过程属性ID | ||||
PA 2.2 | ||||
过程属性名称 | ||||
工作产品管理过程属性 | ||||
过程属性范围 | ||||
工作产品管理过程属性是衡量通过该过程产生的工作产品得到适当管理的程度的指标。 | ||||
过程属性成果 | ||||
1) 定义该过程工作产品的需求。 2) 定义工作产品的存储和控制需求。 3) 对工作产品进行了适当的标识、存储和控制。 4) 根据需要对工作产品进行评审和调整，以满足需求。 | ||||
通用实践 | ||||
GP 2.2.1 定义工作产品的需求。 定义了将要产生的工作产品的内容和结构需求。 确定了工作产品的质量标准。 定义了工作产品的适当评审和批准标准。 注1：文档需求的可能来源可能是，例如，从其他项目中获得的最佳实践或经验教训、标准、组织需求、客户需求等。 注2：可能存在某些类型的工作产品，它们不需要评审或批准，因此无需定义相应的标准。 | ||||
GP 2.2.2 定义工作产品的存储和控制需求。 定义了工作产品的存储和控制需求，包括它们的标识和分发。 注3：确定存储和控制需求的可能来源可能是，例如，法律需求、数据政策、其他项目的最佳实践、工具相关需求等。 注4：工作产品存储的示例包括文件系统中的文件、工具中的票据、Wiki条目、纸质文档等。 注5：在基本实践中需要工作产品状态时，应通过定义的状态模型进行管理。 | ||||
GP 2.2.3 标识、存储和控制工作产品。 标识了要控制的工作产品。 根据需求对工作产品进行存储和控制。 为工作产品建立变更控制。 根据工作产品的存储和控制需求进行版本控制和基线化。 通过适当的机制提供包括修订状态在内的工作产品。 | ||||
GP 2.2.4 评审和调整工作产品。 根据定义的需求和标准对工作产品进行评审。 确保解决由工作产品评审产生的问题。 | ||||
PA 2.2 工作产品管理过程属性 | 成果1 | 成果2 | 成果3 | 成果4 |
输出信息项 | ||||
17-05 工作产品需求 | X | X | ||
18-59 工作产品的评审和批准标准 | X | |||
18-07 质量标准 | X | |||
13-19 评审证据 | X | |||
13-08 基线 | X | |||
16-00 存储库 | X | |||
通用实践 | ||||
GP 2.2.1 定义工作产品的需求 | X | |||
GP 2.2.2 定义工作产品的存储和控制需求 | X | |||
GP 2.2.3 标识、存储和控制工作产品 | X | |||
GP 2.2.4 评审和调整工作产品 | X | |||
以下过程属性，连同先前定义的过程属性，共同表明了这一等级的达成。
过程属性ID | ||||||
PA 3.1 | ||||||
过程属性名称 | ||||||
过程定义过程属性 | ||||||
过程属性范围 | ||||||
过程定义过程属性是衡量在支持已定义过程的部署方面，对标准过程的维护程度的指标。 | ||||||
过程属性成果 | ||||||
1) 开发、建立和维护一个标准过程，该过程描述必须纳入已定义过程中的基本要素。 2) 定义标准过程所需的输入和预期输出。 3) 定义执行标准过程的角色、职责、权限和所需能力。 4) 定义从标准过程中派生出已定义过程的裁剪指南。 5) 确定作为标准过程一部分所需的物理和物质资源以及过程基础设施需求。 6) 确定监测过程有效性、适宜性和充分性的适当方法和所需活动。 | ||||||
通用实践 | ||||||
GP 3.1.1 建立和维护标准过程。 开发一个适当的标准过程，包括所需活动及其交互。 定义标准过程的输入和输出，包括相应的进入和退出标准，以确定与其他过程的交互和顺序。 为标准过程活动分配过程执行角色，包括他们的参与类型、职责和权限。 注1：描述活动中的角色参与的一个示例是RASI/RASIC表示法。 根据需要提供适当的指导、程序和模板，以支持过程的执行。 注2：程序还可以包括要使用的具体方法的描述。 基于已确定的部署需求和标准过程的上下文，定义适当的裁剪指南，包括预定义的明确标准以及预定义和明确的程序。 根据对已部署过程的监测反馈，维护标准过程。 注3：有关如何进行过程改进的指导，请参阅过程改进过程（PIM.3）。 | ||||||
GP 3.1.2 确定所需能力。 为已确定的角色确定执行标准过程所需的能力、技能和经验。 确定、维护和提供适当的资格方法，使已确定的角色获得必要的能力和技能。 注4：资格方法例如培训、指导、自学。 注5：准备工作包括例如确定或定义培训、指导概念、自学材料。 | ||||||
GP 3.1.3 确定所需资源。 确定执行标准过程所需的物理和物质资源以及过程基础设施需求。 注6：这可能包括例如设施、工具、许可证、网络、服务和样件，以支持建立所需的工作环境。 | ||||||
GP 3.1.4 确定监测标准过程的适当方法。 确定监测标准过程有效性和充分性的方法和所需活动。 注7：收集关于标准过程反馈的方法和活动可能是经验教训、过程合规性检查、内部审计、管理评审、变更请求、反映最新水平（如适用的国际标准）等。 定义监测标准过程所需的适当标准和信息。 注8：关于过程执行的信息可能是定性或定量的。 | ||||||
PA 3.1 过程定义过程属性 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 | 成果6 |
输出信息项 | ||||||
06-51 裁剪指南 | X | |||||
08-63 过程监测方法 | X | |||||
10-00 过程描述 | X | X | ||||
10-50 角色描述 | X | |||||
10-51 资格方法描述 | X | |||||
10-52 过程资源和基础设施描述 | X | |||||
通用实践 | ||||||
GP 3.1.1 建立和维护标准过程 | X | X | X | X | ||
GP 3.1.2 确定所需能力 | X | |||||
GP 3.1.3 确定所需资源 | X | |||||
GP 3.1.4 确定监测标准过程的适当方法 | X | |||||
过程属性ID | |||||
PA 3.2 | |||||
过程属性名称 | |||||
过程部署过程属性 | |||||
过程属性范围 | |||||
过程部署过程属性是衡量标准过程作为已定义过程部署的程度，以实现其过程成果。 | |||||
过程属性成果 | |||||
1) 基于适当选择和/或定制的标准过程，部署已定义的过程。 2) 分配执行已定义过程所需的人员到相应的角色，并进行沟通。 3) 确保和监控分配给角色的人员所需的教育、培训和经验。 4) 提供、分配和维护执行已定义过程所需的资源。 5) 收集和分析适当的信息，作为理解过程行为的基础。 | |||||
通用实践 | |||||
GP 3.2.1 部署已定义过程，该已定义过程满足使用标准过程的特定背景要求。 从标准过程中适当选择和/或定制已定义的过程。 验证已定义过程与标准过程要求和定制标准的符合性。 将已定义的过程用作管理过程，以实现过程成果。 注1：标准过程的变更可能要求更新已定义的过程。 | |||||
GP 3.2.2 确保为已定义的角色提供所需的能力。 根据所需的能力和技能，将人力资源分配给已定义的角色。 沟通将人员分配到角色以及执行已定义过程的相应责任和权限。 确定能力和技能方面的差距，并启动和监控相应的资格措施。 度量和监控项目人员的可用性和使用情况。 | |||||
GP 3.2.3 确保提供执行已定义过程所需的资源。 提供、分配和使用执行已定义过程所需的信息。 提供、分配和使用所需的物理和物质资源、过程基础设施和工作环境。 度量和监控资源的可用性和使用情况。 | |||||
GP 3.2.4 监控已定义过程的实施情况。 根据确定的过程监控方法收集和分析信息，以了解已定义过程的有效性和充分性。 将分析结果提供给所有受影响方，并用于确定可以持续改进标准和/或已定义过程的领域。 注2：有关如何进行过程改进的指导，请参阅过程改进过程（PIM.3）。 | |||||
PA 3.2 过程部署过程属性 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 |
输出信息项 | |||||
10-00 过程描述 | |||||
15-54 定制文档 | |||||
14-53 角色分配 | |||||
13-55 过程资源和基础设施文档 | |||||
03-06 过程实施信息 | |||||
通用实践 | |||||
GP 3.2.1 部署已定义的过程 | |||||
GP 3.2.2 确保所需的能力 | |||||
GP 3.2.3 确保所需的资源 | |||||
GP 3.2.4 监控已定义过程的实施情况 | |||||
以下过程属性，连同先前定义的过程属性，共同表明了这一等级的达成。
过程属性ID | ||||||
PA 4.1 | ||||||
过程属性名称 | ||||||
定量分析过程属性 | ||||||
过程属性范围 | ||||||
定量分析过程属性是衡量信息需求的定义程度、过程元素之间的关系识别以及数据收集的一种指标。 | ||||||
过程属性成果 | ||||||
1) 根据相关定义的量化业务目标，建立支持这些目标的过程信息需求。 2) 确定对过程实施有贡献的过程元素之间的可测量关系，以及数据收集技术和数据收集频率。 3) 从过程信息需求中推导出过程度量目标。 4) 选择用于分析所收集数据的技术。 5) 建立支持相关业务目标的过程实施的量化控制限制。 6) 收集、验证和报告度量结果，以监控过程实施的量化目标/目的的达成程度。 注：信息需求通常反映管理、技术、项目、过程或产品需求。 | ||||||
通用实践 | ||||||
GP 4.1.1 确定业务目标。 识别出由定量测量过程支持的业务目标。 | ||||||
GP 4.1.2 建立过程信息需求。 识别已确定的业务目标和定量测量过程的利益相关方，并定义和商定他们的信息需求。 | ||||||
GP 4.1.3 确定过程元素之间的可测量关系。 识别对过程信息需求有贡献的过程元素之间，或过程元素集合之间的关系。 注1：过程元素的例子有工作产品、活动、任务。 | ||||||
GP 4.1.4 推导过程度量方法并选择分析技术。 基于过程元素或过程元素集合的可测量关系，推导出满足既定过程信息需求的过程度量指标。定义数据收集的频率。 选择适合所收集数据的分析技术。 根据需要，定义从基本度量创建派生度量结果的算法和方法。 定义基本度量和派生度量的验证机制。 注2：通常，标准过程定义会扩展，以包括用于过程度量的数据收集。 | ||||||
GP 4.1.5 建立量化控制限制。 为派生的度量指标建立量化控制限制。与过程利益相关方建立协议。 | ||||||
GP 4.1.6 通过执行已定义的过程收集产品和过程度量结果。 为所有已识别的度量指标创建数据收集机制。在已定义的频率内跨过程实例收集所需数据并进行记录。分析度量结果，并向已识别的利益相关方报告。 注3：产品度量可以贡献于过程度量，例如，在给定时间框架内发现的缺陷数量与现场产品缺陷率相关的测试生产率。 | ||||||
PA 4.1 定量分析过程属性 | 成果1 | 成果2 | 成果3 | 成果4 | 成果5 | 成果6 |
输出信息项 | ||||||
18-70 业务目标 | X | X | ||||
07-61 定量过程指标 | X | X | ||||
07-62 过程分析技术 | X | |||||
07-63 过程控制限制 | X | |||||
07-64 过程度量数据 | X | |||||
通用实践 | ||||||
GP 4.1.1 确定业务目标 | X | |||||
GP 4.1.2 建立过程信息 需求 | X | |||||
GP 4.1.3 确定过程元素 之间的可测量关系 | X | |||||
GP 4.1.4 推导过程度量 方法并选择分析技术 | X | X | ||||
GP 4.1.5 建立量化控制限制 | X | |||||
GP 4.1.6 通过执行已 定义的过程收集产品和过程度量结果 | X | |||||
过程属性ID | ||||
PA 4.2 | ||||
过程属性名称 | ||||
定量控制过程属性 | ||||
过程属性范围 | ||||
定量控制过程属性是衡量使用客观数据来管理可预测的过程实施程度的指标。 | ||||
过程属性成果 | ||||
1) 识别过程实施的变化。 2) 通过分析收集的定量数据，确定过程变化的可归因原因。 3) 建立表征过程实施的分布。 4) 采取纠正措施以解决可归因的变化原因。 | ||||
通用实践 | ||||
GP 4.2.1 识别过程实施的变化。 基于收集的定量测量数据，确定过程实例实施与已建立的定量控制限值的偏差。 | ||||
GP 4.2.2 识别变化原因。 分析已确定的过程实施偏差，使用定义的分析技术识别潜在的变化原因。 分布用于定量理解在潜在变化原因影响下的过程实施变化。 分析过程变化的结果。 | ||||
GP 4.2.3 识别并实施纠正措施以解决可归因原因。 向负责采取行动的人员提供结果。 确定并实施纠正措施，以解决每个可归因的变化原因。 监测和评估纠正措施的结果，以确定其有效性。 注1：可归因原因可能表明定义过程中可能存在的问题。 | ||||
PA 4.2 定量控制过程属性 | 成果1 | 成果2 | 成果3 | 成果4 |
输出信息项 | ||||
15-57 定量过程分析结果 | X | X | X | |
08-66 针对定量过程分析中的 偏差采取的措施 | X | |||
通用实践 | ||||
GP 4.2.1 识别过程实施的变化 | X | |||
GP 4.2.2 识别变化原因 | X | X | ||
GP 4.2.3 识别并实施纠正措 施以解决可归因原因 | X | |||
以下过程属性，连同之前定义的过程属性，共同展示了这一等级的实现。
过程属性ID | |||
PA 5.1 | |||
过程属性名称 | |||
过程创新过程属性 | |||
过程属性范围 | |||
过程创新过程属性是衡量通过对过程定义和部署的创新方法进行调查，从而识别出过程变更的程度的指标。 | |||
过程属性成果 | |||
1) 定义了支持相关业务目标的过程创新目标。 2) 分析定量数据以识别创新机会。 3) 识别了源于新技术和过程概念的创新机会。 | |||
通用实践 | |||
GP 5.1.1 为支持相关业务目标的过程定义过程创新目标。 分析新的业务愿景和目标，为新的过程目标和潜在的过程创新领域提供指导。 定义并记录定量和定性的过程创新目标。 | |||
GP 5.1.2 分析过程的定量数据。 识别并分析各过程实例中过程实施的常见变化原因，以定量了解它们的影响。 | |||
GP 5.1.3 识别创新机会。 基于对所分析数据的定量理解，识别创新机会。 识别并评估行业最佳实践、新技术和过程概念。 积极寻求创新机会的反馈。 在评估改进机会时考虑新出现的风险。 | |||
PA 5.1 过程创新过程属性 | 成果1 | 成果2 | 成果3 |
输出信息项 | |||
18-80 改进机会 | X | X | |
15-58 常见变化原因分析结果 | X | ||
通用实践 | |||
GP 5.1.1 为支持相关业务目标的过程定义过程创新目标 | X | ||
GP 5.1.2 分析过程的定量数据 | X | ||
GP 5.1.3 识别创新机会 | X | ||
过程属性ID | |||
PA 5.2 | |||
过程属性名称 | |||
过程创新实施过程属性 | |||
过程属性范围 | |||
过程创新过程实施属性是衡量过程定义、管理和实施的变更达到相关过程创新目标的程度的指标。 | |||
过程属性成果 | |||
1) 根据已定义过程和标准过程的目标，评估所有提议变更的影响。 2) 管理所有商定变更的实施，确保了解任何对过程实施造成的干扰并采取相应行动。 3) 评估基于定量绩效和创新反馈的过程变更的有效性。 | |||
通用实践 | |||
GP 5.2.1 定义和评估提议变更的影响。 根据产品质量和过程实施要求和目标评估特定变更。 考虑对其他已定义和标准过程的影响。 确定过程创新的客观优先级。 组织管理（包括其他相关利益相关方）展示对创新的承诺。 | |||
GP 5.2.2 实施商定的过程变更。 建立一种机制，以有效且完全地将已接受的变更纳入已定义和标准过程中。 实施过程变更，并有效地与所有受影响方沟通。 | |||
GP 5.2.3 评估过程变更的有效性。 测量和比较变更过程的实施和能力与历史数据。 分析变更过程的实施和能力，以确定过程实施是否已针对常见变异原因有所改进。 记录其他反馈，例如标准过程的进一步创新机会。 提一种机制，用于向标准和已定义过程的利益相关方记录和报告分析结果。 | |||
PA 5.2 过程创新实施属性 | 成果1 | 成果2 | 成果3 |
输出信息项 | |||
18-81 改进评估结果 | X | X | |
08-66 定量过程分析中针对偏差的措施 | X | X | |
通用实践 | |||
GP 5.2.1 定义和评估提议变更的影响 | X | ||
GP 5.2.2 实施商定的过程变更 | X | ||
GP 5.2.3 评估过程变更的有效性 | X | ||
