ASPICE

概述

ASPICE（Automotive SPICE）是一种用于汽车行业中软件开发过程改进和能力评定的框架，其主要目的是通过规范化的流程和评估体系来提升软件质量。根据不同的证据，ASPICE可以分为多个部分或等级，每个部分或等级都有其特定的功能和作用。

ASPICE的组成部分

1. 过程参考模型（PRM）：

   • 过程参考模型是ASPICE的核心部分，它定义了软件开发过程中需要遵循的标准流程和实践。这些流程包括需求分析、设计、开发、测试等各个阶段，旨在确保软件开发的规范性和有效性。

2. 过程评估模型（PAM）：

   • 过程评估模型用于评估企业在软件开发过程中的能力水平。它通过一系列的评估指标和量测架构，帮助企业识别改进领域，并提升其软件开发能力。

3. 量测架构：

   • 量测架构用于量化和监控软件开发过程中的各项活动。通过统计分析和数据收集，企业可以对项目进行实时调整，以确保高质量的交付。

ASPICE的能力等级

ASPICE将软件开发能力分为五个等级，从0级到5级，每个等级代表了企业在软件开发过程中的不同成熟度水平：

1. 0级（Incomplete）：未完成级，表示企业的软件开发过程不完整，可能无法独立完成产品开发。

2. 1级（执行级）：已执行级，表示企业能够完成产品开发，但缺乏总结经验、设计规范和管理规范。

3. 2级（管理级）：已管理级，表示企业能够制定项目计划、监控和调整，确保项目有序进行。

4. 3级（建立级）：已建立级，表示企业积累了开发与管理经验，能够根据公司过程规范裁剪和执行项目。

5. 4级（可预测级）：可预测级，表示企业能够通过过程数据的统计分析和预测结果，实时调整项目开发过程，确保高质量的项目交付。

6. 5级（优化级）：优化级，表示企业能够基于商业目标需求反向调整过程，持续改善和优化过程，实现持续改进。

功能与作用

• 过程规范化：ASPICE通过定义标准化的开发流程，帮助企业规范代码开发流程，提高代码质量。
• 能力评估：通过过程评估模型，企业可以评估自身的软件开发能力，并识别需要改进的领域。
• 项目管理：ASPICE强调双向追溯性和一致性，确保工作产品之间的引用和链接，支持覆盖率和影响分析。
• 持续改进：通过量测架构和统计分析，企业可以对项目进行实时调整和优化，确保高质量的交付。

执行流程

系统过程组（SYS）

1. SYS1:需求挖掘

   工作内容：获得利益相关方需求和要求，理解利益相关方期望，达成需求共识，需求变更管理，需求沟通机制

   结果：建立双方持续沟通，定义利益相关方需求，建立变更机制评估需求变更，建立持续监控利益相关方机制，评估能力风险

   交付物：风险管理计划，风险缓解计划，沟通记录，评审记录，变更控制记录，分析报告，利益相关方需求

2. SYS2：系统需求分析

   工作内容：定义系统需求，结构化系统需求，分析系统需求，分析需求对运行环境影响，制定验证准则，建立双响可追溯性，保证一致性，沟通

   结果：建立定义的系统需求，分类系统需求，分析系统需求对环境影响，定义实施优先级，根据需要更新系统需求，建立利益相关方需求和系统需求之间的一致性和双向可追溯性，从成本进度和技术影响来评估系统需求，约定系统需求并与所有受影响相关方沟通

   交付物：沟通记录，评审记录，变更控制记录，追溯记录，分析报告，接口需求规范，系统需求规范，验证准则

3. SYS3:系统架构设计

   工作内容：开发系统架构设计，分配系统需求，定义系统要素的接口，描述动态行为，评估备选的系统架构，建立双向可追溯性，确保一致性，沟通约定的系统架构设计

   交付物：系统架构设计，沟通记录，评审记录

4. SYS4:系统集成与集成测试

   相关内容：制定系统集成策略，制定测试策略，开发测试规范（用例，管理用例），系统集成项，选择测试用例，执行系统集成测试，建立双向可追溯性（测试和需求），总结（测试报告）

   交付物：测试规范，测试计划，系统，沟通记录，评审记录，追溯记录，测试结果

5. SYS5:系统合格性测试

   相关内容：制定系统合格性测试策略，开发合格性测试规范，选择测试用例

   结果：制定计划，制定测试规范，选择测试用例，记录结果，

   交付物：测试规范，测试计划，沟通记录，评审记录，追溯记录，测试结果

软件过程组（SWE）

1. SWE1：软件需求分析（将系统需求转化为软件需求）

   相关内容：定义软件需求（分析哪些参数是标定量，哪些是Signal信号，标定量要写进RAM，随时擦写，不能全局变量），结构化软件需求（软件需求进行分类），分析软件需求（是否能满足需求，有些不能满足的要和客户沟通），对运行环境的影响（与系统的接口，与硬件与底层的接口），制定验证准则，建立双向可追溯性，确保一致性，沟通约定的软件需求

   结果：定义需求和接口，分类底层与应用层需求，软件需求对系统的要求，底层软件需求优先，软件需求变更管理

   输出物：沟通评审记录，变更控制记录，接口需求规范，软件需求规范，验证准则

2. SWE2：软件架构设计

   相关内容：开发软件架构，分配软件需求，定义软件要素的接口（硬件要DBC报文），描述动态行为，定义资源消耗目标（RAM,ROM,FLASH,CPU负载等），评估备选架构（建立准则选择，模快化，复用性，可拓展性），建立双向可追溯性，确保一致性，沟通约定软件架构设计

   输出物：软件架构设计，沟通评审记录，追溯记录，接口需求规范（红色字体，蓝色字体，黄色字体，哪些是强制的，哪些是项目定制的）

3. SWE3：软件详细设计和单元构建

   相关内容:开发软件详细设计（单元模块），定义软件单元接口（知道输入输出），描述动态行为，评估软件详细设计（设计是否方便，交互是否合理，关键性指标，参数怎么设定，技术是不是复杂，软件是不是有风险），追溯性，一致性，沟通约定的软件详细设计，开发软件单元

   结果:要有软件详细设计，说明书，这个模块干嘛的，输入是什么输出是什么；定义接口，动态行为，生成软件详细设计所定义的软件单元

   输出物:软件详细设计文档，软件单元模块…

4. SWE4：软件单元验证

   相关内容：制定包括回归策略在内的软件单元验证策略，制定单元验证准则（MAAB,MISRA），执行软件单元静态验证（静态分析，代码评审，写测试用例，编码规范，结构覆盖率等），测试软件单元（根据策略来测试功能），建立一致性，可追溯性，总结沟通结果

   结果：制定包括回归策略在内的单元验证策略，根据策略制定验证准则以适于提供软件单元符合软件详细设计及非功能性软件需求的依据，根据策略和验证准则，验证软件单元并进行结果记录，建立软件单元和验证准则及验证结果之间的一致性和追溯性，总结单元验证结果并与所有受影响相关方沟通

   输出物：测试计划，测试规范，沟通评审记录，追溯记录，测试验证结果，分析报告

5. SWE5：软件集成和集成测试（把所有软件模块集成起来再和底层软件集成，底层软件作用就是CAN通信，Signal通信等功能，就是软件和硬件通信）

   相关内容:制定软件集成策略，制定包含回归策略在内的软件集成测试策略，开发软件集成测试规范（单元m/s,km/h接口，资源消耗的问题），集成软件单元和软件项，选择测试用例，执行软件集成测试（测试报告，MIL,SIL），建立一致性可追溯性，总结沟通测试结果

   结果:制定与项目计划，发布计划和软件架构设计相一致的软件集成策略及集成软件项，制定包括软件回归策略在内的软件集成测试策略，以测试软件单元之间和软件项之间的交互，根据软件集成测试策略，开发软件集成测试规范，以适于提供集成的软件项目符合软件架构设计（包括软件单元之间和软件项目之间的接口）的证据，根据集成策略集成软件单元和软件项直至完整的集成软件，根据软件集成测试策略发布计划选择软件集成测试规范中的测试用例，使用选定的测试用例测试集成了的软件项目并记录测试结果，建立软件架构设计要素与软件集成测试规范中的测试用例间的一直性双向可追溯性建立测试用例和测试结果之间的一致性和双向可追溯性，总结软件集成测试结果并与受影响方沟通

   输出物:软件项，集成软件，测试计划，测试规范，沟通评审记录，追溯记录，测试结果，编译清单（测试过程中模型编译成代码，背靠背测试，MathWorks，Target-link dSpace）

6. SWE6：软件合格性测试

   相关内容:制定包括回归策略在内的软件合格性测试策略（MIL测试建立各种场景），开发软件合格性测试规范，选择测试用例，测试集成软件，建立双向可追溯性和一致性，总结沟通结果

   结果:制定软件合格性测试策略，根据策略开发软件合格性测试规范，根据测试策略和测试规范选择测试用例，用测试用例进行软件测试记录测试结果，建立软件需求和合格性测试规范中测试用例的一致性和双向可追溯性，测试用例和测试结果之间的双向可追溯和一致性，总结软甲你测试结果

   输出物:测试规范，测试计划，沟通评审记录，追溯记录，测试结果

相关术语

BP(Basic Practice)

在ASPICE（高级软件过程改进和能力评估）中，BP（Basic Practice，基本实践）是定义了每个过程域所需的具体活动和任务的实践。这些实践旨在确保过程的实施能够达到预期的目标，并提供明确的指导以帮助组织改进其软件开发和管理流程。

例如，在ASPICE指南中，BP可以包括以下内容：

1. 问题解决：BP1至BP9涉及制定问题解决策略、识别和记录问题、跟踪问题状态、分析问题趋势等，以确保问题能够被有效管理和解决。

2. 需求管理：BP用于获取利益相关方的需求和要求，确保需求的一致性和可追溯性。

3. 设计与验证：BP用于制定详细的设计、定义软件组件的接口、描述动态行为、评估软件设计等，以确保设计的质量和一致性。

4. 测试与验证：BP用于选择测试用例、执行软件集成测试、确保双向可追溯性等，以保证软件测试的全面性和有效性。

5. 配置管理：BP用于定义访问权限、识别配置项、创建基线等，以确保配置管理的规范性和一致性。

6. 项目管理：BP用于定义工作范围、评估项目可行性、确保项目计划的一致性等，以支持项目的顺利实施。

支持过程组（SUP）

SUP.9

SUP.9（问题解决管理）是一个关键的过程，旨在确保项目中出现的问题能够被及时、有效地识别、分析、管理和解决。以下是SUP.9的具体内容和细节：

1. 问题识别与登记：首先，需要准确记录项目中出现的缺陷、故障、不一致等问题，并为每个问题分配状态以便跟踪。这一步骤确保了问题信息的准确性和完整性。

2. 问题分析与评估：对问题进行深入分析，确定其成因和影响。这包括调查问题的原因，评估其对其他系统或受影响方的影响，并根据严重性、关键性和紧迫性等因素对问题进行分类。

3. 授权紧急解决行动：如果问题需要立即解决，则获得授权采取紧急行动。这可能涉及短期的应急措施，以防止问题进一步恶化。

4. 发出警报通知：当问题可能对其他系统或受影响方产生重大影响时，应发出警报通知相关方。

5. 启动问题解决：根据问题的分类，采取适当的长期行动来解决问题。这可能包括审查这些行动或发起变更请求，并确保与短期紧急解决行动的一致性和协调性。

6. 跟踪问题关闭状态：持续跟踪问题的关闭状态，包括所有相关的变更请求，并确保相关利益攸关方接受问题已解决。

7. 报告问题解决活动的状况：收集和分析问题解决管理数据，识别趋势并启动相关行动。定期向相关利益攸关方报告数据分析结果、识别的趋势和问题解决活动的状况。

8. 建立问题管理流程和工具：明确定义问题管理流程，包括输入、输出和角色责任，并选择适合的问题管理工具，用于记录、分配、追踪和统计。

9. 培训相关人员：为项目参与人员提供问题解决管理培训，确保他们了解流程和工具的使用。

SUP.9.BP的步骤：

ASPICE的SUP.9.BP（基本实践）包括以下内容：

1. SUP.9.BP1：制定问题解决管理策略

   制定问题解决管理策略，包括问题解决活动、问题状态模型、警报通知、执行这些活动的责任以及紧急解决策略。定义受影响方的接口并维护该定义。

2. SUP.9.BP2：识别和记录问题
   每个问题都被唯一识别、描述和记录。为每个问题分配一个状态以方便追踪，并提供支持信息以复现和诊断问题。

3. SUP.9.BP3：记录问题状态
   根据状态模型，给每个问题分配状态以便于跟踪。

4. SUP.9.BP4：诊断问题的原因，确定问题的影响 调查问

   题并确定其原因和影响，以便对问题进行分类并确定适当的行动。如果问题对其他系统或受影响方有较大影响，则需要发出警报通知。

5. SUP.9.BP5：授权紧急解决行动

   根据分类采取适当行动来解决问题，包括审查这些行动或发起变更请求。这包括与短期紧急解决方案同步和一致（如果适用）。

6. SUP.9.BP6：发出警报通知

   跟踪问题的状态至关闭，包括所有相关的变更请求。相关利益方接受问题的关闭。

7. SUP.9.BP7：启动问题的解决
   收集和分析问题解决管理数据，识别趋势并采取相关行动。定期向相关利益方报告数据分析结果、识别出的趋势以及问题解决活动的进度。

8. SUP.9.BP8：跟踪问题直至关闭

   如果问题需要紧急解决，根据策略获得授权进行立即行动。

9. SUP.9.BP9：分析问题趋势

SUP.10

SUP.10 是 ASPICE 中的一个支持过程，主要用于管理问题的识别、跟踪和解决。其核心目的是在系统和软件开发生命周期中确保所有问题（如缺陷、偏差或风险）被有效管理，并最终得以解决，从而提升产品质量和开发效率。

SUP.10 的关键任务：

1. 记录问题：将发现的所有问题（如软件缺陷、需求冲突或集成失败）记录下来，确保没有遗漏。
2. 分类与分配：对问题进行分类（例如严重性、优先级、类型）并分配给合适的团队或责任人。
3. 跟踪状态：持续跟踪问题的生命周期状态，从“新建”到“解决”再到“关闭”。
4. 分析问题：找出问题的根本原因（Root Cause Analysis, RCA），并提出适当的解决方案。
5. 验证解决方案：确保问题的解决方案已经有效实施，并不会引入新的问题。
6. 监控与报告：提供问题状态的监控和统计报告，以便管理层做出决策。

目标：

• 确保所有问题都被清晰地记录、妥善解决。
• 提高开发过程中问题处理的透明度和效率。
• 通过根本原因分析，减少重复问题发生的可能性。
• 支持产品质量和项目进度的持续改进。

SUP.10.BP从大方向上分为三步：

1. BP1-BP3：问题的发现和初步管理（识别、分类、分配）。
2. BP4-BP6：问题的深入处理（分析、解决、验证）。
3. BP7-BP9：问题的闭环管理和改进（关闭、监控、总结）。

SUP.10.BP的详细步骤：

1. BP1：问题识别和记录
   • 作用:确保所有在开发过程中发现的问题（如缺陷、偏差）都能被识别并清晰地记录下来。
   • 关键活动：
     • 使用问题管理工具或系统，记录问题的基本信息，包括描述、来源、发生时间等。
     • 确定问题的初始状态，例如“新建”或“待处理”。
   • 输出：已记录的问题列表。
2. BP2：问题分类和优先级设定
   • 作用：对记录的问题进行分类，并根据其影响程度或紧急性设定优先级，以便合理分配资源。
   • 关键活动：
     • 确定问题的严重性（Critical、Major、Minor 等）。
     • 分类问题类型（需求缺陷、实现问题、性能问题等）。
     • 为问题设定处理优先级（高、中、低）。
   • 输出：具有分类和优先级信息的问题列表。
3. BP3：问题分配
   • 作用：将每个问题分配给合适的责任人或团队，明确问题的处理者。
   • 关键活动：
     • 确定处理问题所需的技能或权限。
     • 指派责任人，并设定处理时限或预期解决日期。
   • 输出：分配了责任人的问题记录。
4. BP4：问题分析
   • 作用：深入分析问题的根本原因，评估其对项目的影响，并制定解决方案。
   • 关键活动：
     • 进行根本原因分析（Root Cause Analysis, RCA）。
     • 使用工具和方法（如鱼骨图、5 Whys 等）分析问题。
     • 记录分析结果和建议的解决措施。
   • 输出：
     • 问题分析报告。
     • 提议的解决方案。
5. BP5：问题解决
   • 作用：根据分析结果实施解决方案，修复问题。
   • 关键活动：
     • 修改设计、代码或文档以解决问题。
     • 确保实施的解决方案符合相关要求。
     • 执行回归测试或验证测试，确认问题已解决。
   • 输出：
     • 修复完成的问题。
     • 更新的文档或交付物。
6. BP6：问题验证
   • 作用：确认问题的解决方案已经正确实施，并且没有引入新的问题。
   • 关键活动：
     • 针对问题对应的测试用例进行执行。
     • 验证解决方案是否符合问题的初始描述和需求。
     • 记录验证结果。
   • 输出：
     • 验证通过的问题。
     • 验证记录。
7. BP7：问题关闭
   • 作用：将已验证的问题标记为关闭，结束问题的生命周期。
   • 关键活动：
     • 确保所有相关方（如客户、质量团队）同意问题可以关闭。
     • 在问题管理工具中将状态更新为“关闭”。
     • 归档问题的所有相关记录，作为经验库的一部分。
   • 输出：问题关闭记录。
8. BP8：问题状态监控
   • 作用：定期监控问题的状态，确保问题的解决过程符合预期。
   • 关键活动：
     • 跟踪问题的生命周期状态（如“新建”、“分析中”、“已解决”、“已关闭”）。
     • 定期生成问题状态的统计报告。
     • 识别未按时解决或处理延迟的问题。
   • 输出：
     • 问题状态报告。
     • 识别到的异常问题。
9. BP9：问题管理的经验总结
   • 作用：分析已解决的问题，提取经验和教训，用于未来的改进和问题预防。
   • 关键活动：
     • 汇总问题的根本原因和解决方案。
     • 提出改进建议，优化过程。
     • 将经验记录到组织的知识库中。
   • 输出：
     • 改进建议。
     • 更新的知识库。

系统过程组（SYS）

SYS.3

输出物：

1. 系统架构设计方案
2. 系统架构设计计划检查表
3. 系统架构设计
4. 系统架构设计检查表
5. 系统架构设计评估报告
6. 系统架构设计流程检查表

SYS.3的BP过程为：

1. SYS.3_BP1: 开发系统架构设计。开发，分析并文档化系统架构设计， 该系统架构设计规范中包括基于系统功能性需求和非功能性需求定义系统架构，系统架构设计的开发通常包括在适当的各层级上分解成元素，并对各元素进行详细说明。

2. SYS.3_BP2: 分配系统需求。将SYS.2过程域中定义的系统需求分配给系统架构设计的元素。

3. SYS.3_BP3: 描述动态行为，定义系统元素的接口。 识别、分析，开发并文档化每个系统元素之间的接口信息。

   动态行为取决于运动模式，如启动、关机、正常模式、标定和诊断

4. SYS.3_BP4: 描述系统元素的静态行为和动态行为。 评估，分析并文档化系统元素之间相互作用的静态行为和动态行为，其中，动态行为取决于运行模式（例如:启动、关机、正常模式、标定和诊断等方面）。

5. SYS.3_BP5: 评估，分析备选的系统架构。定义当前系统架构和备选系统架构方案，以及架构设计的评估准则。根据已定义的评估准则，评估备选的系统架构。记录被选定的系统架构的选择理由。其中，评估准则可以包括质量特性（模块性、可维护性、可扩展性、可扩缩性、可靠性、安全（security）可实现性、易用性）和开发-购买-重用分析的结果。

6. SYS.3_BP6: 建立双向可追溯性。建立系统需求和系统架构设计的元素之间的双向可追溯性。双向可追溯性覆盖系统需求向系统架构设计的要素的分配。双向可追溯性有助于覆盖率、一致性和影响分析。

7. SYS.3_BP7: 确保一致性。确保系统需求和系统架构设计间的一致性。一致性由双向可追溯性支持，并可通过评审记录来证明。

8. SYS.3_BP8: 沟通约定的系统架构设计。与所有相关方以及相关的工程师沟通已约定的系统架构设计规范以及对系统架构设计规范针对评审问题进行更新。

软件过程组（SWE）

软件需求分析（SWE.1）

软件需求分析过程的目的是将系统需求中与软件相关的部分转化为一组软件需求。

基本实践为：

1. SWE.1.BP1：定义软件需求。 使用系统需求和系统架构及其变更来识别软件所需的功能和能力。在软件需求规范中定义功能性和非功能性软件需求。

   输出的成果为：

   1. 定义了系统中分配给软件要素的软件需求及其接口；
   2. 根据需要更新了软件需求；
   3. 从成本、进度和技术影响来评估软件需求；

   [!tip]

   1. 影响功能和能力的应用参数是系统需求的一部分。
   2. 如果只有软件开发，系统需求和系统架构是指给定的运行环境。在这种情况下，应将利益相关方需求作为识别软件所需功能和能力以及识别影响软件功能和能力的应用参数的基础。

   

2. SWE.2.BP2:结构化系统需求。 在软件需求规范中结构化软件需求，例如

   1. 按项目相关集群进行分组；
   2. 按项目中逻辑顺序排序；
   3. 基于项目相关准则进行分类；
   4. 根据利益相关方需要进行优先级排序

   输出的成果为：

   1. 对软件需求进行分类，并分析了其正确性和可验证性；
   2. 根据需要更新了软件需求；

   [!tip]

   优先级排序通常包括将软件内容分配给已计划的发布。

3. SWE.1.BP3:分析软件需求。 分析已定义的系统需求（包括它们的相互依赖关系），以确保正确性、技术可行性和可验证性，并且支持风险识别。分析对成本、进度和技术的影响。

   输出的成果为：

   1. 对软件需求进行分类，并分析了其正确性和可验证性；
   2. 从成本、进度和技术影响来评估软件需求；

   [!tip]

   对成本和进度的影响分析有助于项目估算的调整。

   针对于软件，还可考虑如下风险：

   1. 不充分的解决方案、测试方案
   2. 不完整的开发及测试工具链
   3. 非功能需求能否被充分满足
   4. 自动生成代码导致测试工作量的负荷影响等

4. SWE.1.BP4:分析对运行环境的影响。 分析软件需求对系统要素接口及运行环境的影响。 [成果3,7]

   输出的成果为：

   1. 分析了软件需求对运行环境的影响；
   2. 从成本、进度和技术影响来评估软件需求；

   [!tip]

   运行环境是指软件运行所在的系统（例如：硬件、操作系统等）。

   Guideword	Deviation	Possible Cause	Consequences	Measures
   Too often	High bus load	Non-compliance with the bus spec, calling party sending even if no one listens	Communication breakdown, messages get lost	1. Ensure that bus spec is know 2. Ensure that the bus spec is understood 3. Verify through design review Implement specific bus load tests
   Too rarely	Faulty communication	Non-compliance with the bus spec, calling party not sending if someone listens	Communication breakdown, messages missing	4. See above

5. SWE.1.BP5:制定验证准则。 对每个软件需求指定验证准则，定义定性的和定量的措施用于需求验证。

   输出的成果为：

   1. 对软件需求进行分类，并分析了其正确性和可验证性；
   2. 从成本、进度和技术影响来评估软件需求；

   [!tip]

   1. 验证准则证明了需求可以在约定的约束范围内得到验证，并且通常被用作软件测试用例开发或其他证明符合系统需求的验证措施的输入。
   2. 测试不能覆盖的验证由SUP.2覆盖。

6. SWE.1.BP6:建立双向可追溯性。 系统需求与软件需求之间的双向可追溯性，建立系统架构设计与软件需求之间的双向追溯性。

   输出的成果为：

   1. 在系统需求与软件需求之间、在系统架构设计与软件需求之间建立了一致性和双向可追溯性；

   [!tip]

   1. 应通过建立同时满足项目和组织要求的方法来避免冗余。
   2. 双向可追溯性有助于覆盖率、 一致性和影响分析。

   

7. SWE.1.BP7:确保一致性。 确保系统需求与软件需求之间的一致性，确保系统架构与软件需求之间的一致性。

   输出成果为：

   1. 在系统需求与软件需求之间、在系统架构设计与软件需求之间建立了一致性和双向可追溯性；

   [!tip]

   1. 一致性由双向可追溯性支持，并可通过评审记录来证明。
   2. 如果只有软件开发，系统需求和系统架构是指软件的运行环境。在这种情况下，必须确保利益相关方需求与软件需求之间的一致性和双向可追溯性。

8. SWE.1.BP8:沟通约定的软件需求。 与所有相关方沟通约定的软件需求及软件需求的更新。

   输出成果为：

   1. 约定了软件需求，并与所有受影响方沟通。

SWE.1.BP之间的关系为：

成功实施这个过程的结果是：

1. 定义了系统中分配给软件要素的软件需求及其接口；
2. 对软件需求进行分类，并分析了其正确性和可验证性；
3. 分析了软件需求对运行环境的影响；
4. 定义了软件需求实施的优先级；
5. 根据需要更新了软件需求；
6. 在系统需求与软件需求之间、在系统架构设计与软件需求之间建立了一致性和双向可追溯性；
7. 从成本、进度和技术影响来评估软件需求；
8. 约定了软件需求，并与所有受影响方沟通。

软件架构设计（SWE.2）

软件架构设计过程的目的是：建立软件架构设计，识别将哪些软件需求分配给软件的哪些要素，并依照已定义的准则评估软件架构设计。

SWE.2是软件架构设计，主要内容有：

1. 静态架构

   这部分需要定义好软件模块（Component/Element）有哪些，模块间的一个交互关系的定义，主要是一些接口函数的定义，需要定义清楚函数类型（返回值，或者无返回），参数及类型。假如要做一个电压检测的功能，需要读取ADC采集到的值然后再做其他逻辑判断，那么可以定义如下的一个接口交互关系：

   

   由上图可知，对于电压检测这个功能，我们需要一个读取电压ADC值的接口，所以我们可以将接口定义如下：

   uint16 u16GetADCValue(uint8 ch_id);

   由上述定义我们就可以明确，需要一个返回值类型为uint16（必要时可以定义返回值范围），参数为uint8（必要时可以定义入参范围，为软件集成测试定义一个明确的测试范围）的一个接口，这样可以指导软件架构的下游活动，例如详细设计（Detailed Design）和软件集成测试（Software Integration and Integration Test）去实施。

2. 动态架构

   这部分需要定义模块的动态合作关系，例如一些时序等，还是以上面讲到的电压检测功能为例，可以画出动态架构图如下：

   

   由上图可以看出MCAL_TASK和VOL_TASK的调用先后关系，需要ADC先处理完得到ADC值，电压检测模块才去调用u16GetADCValue这个接口获取电压值，然后再做进一步的逻辑判断。

   如果有一些状态转换的需求，需要定义一些状态及状态跳转的条件等，例如：

   

基本实践为：

1. SWE.2.BP1:开发软件软件设计。 开发并文档化软件架构设计，该设计基于软件功能性需求和非功能性需求定义软件要素。

   输出的成果为：

   1. 定义了识别软件要素的软件架构设计；

   [!tip]

   将软件分解为适当的各层级上的要素，直至软件架构设计的最低层级要素，即详细设计中描述的软件组件。

   例：基于AUTOSAR架构进行开发

   

2. SWE.2.BP2:分配软件需求。 将软件需求分配给软件架构设计的要素。

   输出的成果为：

   1. 将软件需求分配给软件的要素；

3. SWE.2.BP3:定义软件要素的接口。 识别、开发并文档化每个软件要素的接口。

   输出的成果为：

   1. 定义了每个软件要素的接口；

4. SWE.2.BP4:描述动态行为。 评估并文档化软件要素之间的时许和动态交互，以满足系统所需的动态行为。

   输出的成果为：

   1. 定义了软件要素的动态行为和资源消耗目标；

   [!tip]

   1. 动态行为取决于运行模式（例如：启动、关机、正常模式、标定、诊断等）、进程及进程间相互通信、任务、线程、时间片、中断等。
   2. 在评估动态行为时，宜考虑目标平台和目标对象的潜在负载。

5. SWE.2.BP5:定义资源消耗目标。 在适当的层级上确定并文档化软件架构设计的所有相关要素的资源消耗目标。

   输出的成果为：

   1. 定义了软件要素的动态行为和资源消耗目标；

   [!tip]

   资源消耗通常取决于资源，如：内存（ROM、 RAM、外部/内部EEPROM或数据闪存）、 CPU负载等。

6. SWE.2.BP6:评估备选的软件架构。 定义架构的评估准则。根据定义的准则评估备选的软件架构，记录被选定的软件架构的选择理由。

   输出的成果为：

   1. 定义了识别软件要素的软件架构设计；
   2. 将软件需求分配给软件的要素；
   3. 定义了每个软件要素的接口；
   4. 定义了软件要素的动态行为和资源消耗目标；
   5. 建立了软件需求和软件架构设计之间的一致性和双向可追溯性；

   [!tip]

   评估准则可包括质量特性（模块性、可维护性、可扩展性、可扩缩性、可靠性、安全（security）可实现性和易用性）以及开发-购买-重用分析的结果。

7. SWE.2.BP7:建立双向可追溯性。 建立软件需求和软件架构设计的要素之间的双向可追溯性。

   输出的成果为：

   1. 建立了软件需求和软件架构设计之间的一致性和双向可追溯性；

   [!tip]

   1. 双向可追溯性覆盖软件需求向软件架构设计的要素的分配。
   2. 双向可追溯性有助于覆盖率、 一致性和影响分析。

8. SWE.2.BP8:确保一致性。 确保软件需求和软件架构设计之间的一致性。

   输出的成果为：

   1. 定义了识别软件要素的软件架构设计；
   2. 将软件需求分配给软件的要素；
   3. 建立了软件需求和软件架构设计之间的一致性和双向可追溯性；
   4. 约定了软件架构设计，并与所有受影响方沟通

   [!tip]

   一致性由双向可追溯性支持，并可通过评审记录来证明。

9. SWE.2.BP9:沟通约定的软件架构设计。 与所有相关方沟通已约定的软件架构设计及对软件架构设计的更新。

   输出的成果为：

   1. 约定了软件架构设计，并与所有受影响方沟通

SWE.2.BP之间的关系：

成功实施这个过程的结果是：

1. 定义了识别软件要素的软件架构设计；
2. 将软件需求分配给软件的要素；
3. 定义了每个软件要素的接口；
4. 定义了软件要素的动态行为和资源消耗目标；
5. 建立了软件需求和软件架构设计之间的一致性和双向可追溯性；
6. 约定了软件架构设计，并与所有受影响方沟通

软件详细设计与单元构建（SWE.3）

软件详细设计和单元构建过程的目的是：为软件组件提供经过评估的详细设计，并定义和生成软件单元。

基本实践为：

1. SWE.3.BP1:开发软件详细设计。 开发软件架构设计中定义的各软件组件的详细设计，该设计基于软件功能性需求和非功能性需求定义软件单元。

   输出成果为

   1. 开发了描述软件单元的详细设计；

2. SWE.3.BP2:定义软件单元的接口。 识别、定义和文档化各软件单元的接口。

   输出成果为：

   1. 定义了各软件单元的接口；

3. SWE.3.BP3:描述动态行为。 评估并文档化相关软件单元之间的动态行为和交互。

   输出成果

   1. 定义了软件单元的动态行为；

   [!tip]

   并非所有的软件单元都有动态行为可描述。

   为了描述一个软件组件在运行时的动态行为, 需要进行行为描述, 例如:

   1. 状态机
   2. 时序图
   3. 用例图

   另外，响应时间需要考虑定义如下:

   1. 任务
   2. 线程概念
   3. 时间片
   4. 中断
   5. 接口

4. SWE.3.BP4:评估软件详细设计。 从互操作性、交互、关键性、技术复杂性、风险和可测试性方面对软件详细设计进行评估。

   输出成果为：

   1. 开发了描述软件单元的详细设计；
   2. 定义了各软件单元的接口；
   3. 定义了软件单元的动态行为；
   4. 建立了软件需求与软件单元之间的一致性和双向可追溯性；建立了软件架构设计与软件详细设计之间的一致性和双向可追溯性；建立了软件详细设计与软件单元之间一致性和双向可追溯性；

   [!tip]

   评估结果能作为软件单元验证的输入。

5. SWE.3.BP5:建立双向可追溯性。 建立软件需求与软件单元之间的双向可追溯性。建立软件架构设计与软件详细设计之间的双向可追溯性。建立软件详细设计与软件单元之间的双向可追溯性。

   输出成果为

   1. 建立了软件需求与软件单元之间的一致性和双向可追溯性；建立了软件架构设计与软件详细设计之间的一致性和双向可追溯性；建立了软件详细设计与软件单元之间一致性和双向可追溯性；

   [!tip]

   1. 对以上方法进行组合，覆盖项目和组织需要， 避免冗余。
   2. 双向可追溯性有助于覆盖率、一致性和影响分析。

6. SWE.3.BP6:确保一致性。 确保软件需求与软件单元之间的一致性。确保软件架构设计、软件详细设计及软件单元之间的一致性。

   输出成果为：

   1. 建立了软件需求与软件单元之间的一致性和双向可追溯性；建立了软件架构设计与软件详细设计之间的一致性和双向可追溯性；建立了软件详细设计与软件单元之间一致性和双向可追溯性；

   [!tip]

   一致性由双向可追溯性支持，并可通过评审记录来证明。

   

   模型：详细设计、单元需要符合建模规范（例MAAB）

   代码：详细设计、单元需要符合编码规范（例MISRA C）

7. SWE.3.BP7:沟通约定的软件详细设计。 与所有相关方沟通已约定的软件详细设计及对软件详细设计的更新。

   输出成果为：

   1. 约定了软件详细设计及该设计与软件架构设计的关系，并和所有受影响方沟通；

8. SWE.3.BP8:开发软件单元。 根据软件详细设计，开发并文档化各软件单元的可执行形式。

   输出的成果为：

   1. 生成了软件详细设计所定义的软件单元。

   [!tip]

   软件单元不得包含详细设计中未说明的内容，因为这支持可维护性或缺陷分析。

实践的关联为：

成功实施这个过程的结果是：

1. 开发了描述软件单元的详细设计；
2. 定义了各软件单元的接口；
3. 定义了软件单元的动态行为；
4. 建立了软件需求与软件单元之间的一致性和双向可追溯性；建立了软件架构设计与软件详细设计之间的一致性和双向可追溯性；建立了软件详细设计与软件单元之间一致性和双向可追溯性；
5. 约定了软件详细设计及该设计与软件架构设计的关系，并和所有受影响方沟通；
6. 生成了软件详细设计所定义的软件单元。

软件单元验证（SWE.4）

软件单元验证过程的目的是：验证软件单元，以提供软件单元符合软件详细设计和非功能性软件需求的证据。

类别	SWE4 软件单元验证	SWE5 软件集成和集 成测试	SWE6 软件合 格性测 试	SYS4 系统集成和集 成测试	SYS5 系统合格 性测试
制定策略	√ (测试)	√ (集成+测试)	√ (测试)	√ (集成+测试)	√ (测试)
开发测试规格书	√ (静态+动态)	√	√	√	√
执行集成		√		√
选择测试用例	√	√	√	√	√
执行测试	√ (静态+动态)	√	√	√	√
建立追溯一致性	√	√	√	√	√
总结沟通	√	√	√	√	√

基本实践为：

SWE.4.BP1:

制订包括回归策略在内的软件单元验证策略。 制订软件

单元验证策略（包括软件单元变更时实施再验证的回归策略）。验

证策略应定义如何提供软件单元符合软件详细设计和非功能性需求

的证据。

[成果1]

成功实施这个过程的结果是：

1. 制订了包括回归策略在内的软件单元验证策略，以验证软件单元；
2. 根据软件单元验证策略，制订了软件单元验证准则，以适于提供软件单元符合软件详细设计及非功能性软件需求的证据；
3. 根据软件单元验证策略及软件单元验证准则， 验证了软件单元并记录了结果；
4. 建立了软件单元、验证准则及验证结果之间的双向可追溯性和一致性；
5. 总结了单元验证结果，并与所有受影响方沟通。

SWE.5

SWE.5是软件集成与集成测试，SWE.5的主要目标和成果为：

1. 目标：

   • 将软件单元集成到更大的软件项目中，形成完整的集成软件解决方案。
   • 确保集成后的软件组件能够满足软件架构设计的要求，包括模块间的接口和数据流。
   • 通过集成测试验证软件组件的正确性和一致性，提供符合性证据。

2. 成果：

   • 制定软件集成策略，该策略应与项目计划、发布计划和软件架构设计一致。
   • 建立全面的软件集成测试策略，涵盖回归测试，以评估软件单元和组件之间的交互。
   • 创建符合测试策略的软件集成测试规范，以证明集成后的软件组件与架构设计的一致性。
   • 记录集成测试的结果和日志，确保所有测试活动都有充分的覆盖率。

SWE.5的基本实践（BP）

SWE.5包含多个基本实践（BP），每个BP都有其特定的目标和要求：

1. BP1：制定软件集成验证措施：

   • 针对软件架构中定义的软件组件及其接口的行为和接口进行验证。
   • 包括技术、进入和退出标准以及通过/失败标准。

2. BP2：选择测试用例：

   • 根据软件集成测试策略选择测试用例，确保测试用例具有足够的覆盖率。
   • 测试用例的选择需考虑交付物的使用场景（如测试台、测试轨道或公共道路等）。

3. BP3：开发软件集成测试规范：

   • 根据软件集成测试策略开发测试规范，包括针对每个集成软件项的测试用例。
   • 测试规范应能够证明集成后的软件项与架构设计的一致性。

4. BP4：执行软件集成测试：

   • 使用选定的测试用例执行软件集成测试，并记录测试结果和日志。
   • 确保所有模块间的接口和数据流符合预期。

5. BP5：总结和沟通结果：

   • 总结集成测试的结果，并与所有相关方沟通。
   • 提供详细的测试报告和分析，以支持后续的改进活动。

SWE.6

SWE.6是软件合格性测试，SWE.6的具体内容和目标为：

1. 过程目标：

   • 确保集成软件经过测试，以提供符合软件需求的证据。
   • 检查软件是否符合要求，并确定它们是否得到充分满足和正确实施。

2. 基础实践（BP）：

   • BP1：制定软件资格测试策略，包括与回归测试策略的一致性。
   • BP2：选择验证措施，根据选择标准记录验证措施的选择。
   • BP3：使用选定的验证措施对集成软件进行验证，并记录验证结果。
   • BP4：确保验证措施与软件需求的一致性，并建立验证结果与验证措施之间的双向可追溯性。
   • BP5：总结和传达软件资格测试结果，向所有受影响方沟通。
   • BP6：建立软件需求与软件资格测试规范（包括测试案例）以及测试案例与测试结果之间的一致性和双向可追溯性。
   • BP7：总结和沟通测试结果，提供必要的信息以便其他方判断结果。

3. 输出工作产品：

   • 测试规范（Test Specification）
   • 测试计划（Test Plan）
   • 测试用例（Test Cases）
   • 测试结果（Test Results）
   • 沟通记录（Communication Records）
   • 审查记录（Review Records）
   • 可追溯记录（Traceability Records）。

示例

问题：

假设现在车身控制中外灯系统中的近光灯部分需求点为例

1. SWE.1：在进行SWE.1之前，开发者应该接收来自SYS.2、SYS.3的输入，即系统需求和系统架构设计。当接收到系统需求和系统架构设计之后，开发者应该（必须）遵循SWE.1.BP来执行过程，执行流程为：

   1. 定义软件需求
   2. 结构化软件需求
   3. 分析软件需求
   4. 分析需求在操作环境中的影响
   5. 确保一致性和双向可追溯性
   6. 与利益相关者对系统需求及其影响沟通达成一致

   在此过程中，应该产生以下需求：

   SW_REQ-10001：若整车电源模式是ON，车辆应在打开近光灯开关被按下时打开近光灯；

   SW_REQ-10002：若整车电源模式是ON，车辆应在关闭所有灯光被按下时关闭近光灯；

   SW_REQ-10003：车辆应为用户提供信息（近光指示灯）以提示近光灯的工作状态。

   架构化需求及环境模块影响分析：

   

2. SWE.2:SWE.1之后开始软件架构设计（SWE.2），所以SWE.2的输入来源于SWE.1；SWE.2目的是建立一个与软件需求一致的且分析过的软件架构，包括静态和动态方面。在此过程中需要使用以下BP来执行：

   1. 定义静态的软件架构

   2. 定义动态的软件架构

   3. 分析软件架构

   4. 确保一致性并建立双向可追溯性

   5. 沟通商定的系统架构

   以上述SW_REQ-10001~ SW_REQ-10003需求为例：

   静态架构设计：定义软件模块的静态信息，如接口名、信号名、模块名等；

   

   动态架构示意：重点在于模块的动态交互、时序等逻辑体现

   

   

3. SWE.3:软件详细设计和单元构建；目的是建立与软件体系结构一致的软件详细设计，包括静态和动态方面，并构建与软件详细设计一致的软件单元。它的输入来源为SWE.1和SWE.2。在此过程中，开发工程师应遵循以下BP实现：

   1. 定义软件详细配置
   2. 定义软件详细模块交互
   3. 开发并配置模块单元
   4. 确保一致性并建立双向可追溯性
   5. 沟通商定的软件详细设计和开发的软件单元

   这一环节是对软件架构设计中的SW Component的进一步设计，同样的也包含了动态详细设计与静态详细设计两个方面；通常需要识别出SWE.2环节中设定的软件模块SWC中包含哪些子模块，不过，在通常的正向开发过程中，SWE.2执行过程已经完成这一步分析。

   如LoBeam SWC中包含了SW unit：电源判断模块与 SW unit：灯光判断模块两个软件子模块；对SW uint进行更详细的设计：定义操作函数、设定或理解交互接口；如果涉及到复杂的数据类型或者算法，也需要在这个环节完成；

   

4. SWE.4:软件单元验证；目的是验证软件单元是否与软件详细设计一致，提供证据证明软件单元符合软件详细设计和非功能软件需求；开发工程师需要遵循以下BP来实现：

   1. 规定软件单元验证措施
   2. 选择软件单元验证措施
   3. 验证软件单元
   4. 确保一致性，建立双向可追溯性
   5. 总结并交流结果

   所要验证的对象来自于SWE.3的输出；

   根据BP，实际操作流程可以如下：

   1. 收齐输入物（被测模型/代码），即SWE.1需求，与SWE.3代码/模型

   2. 搭建测试环境

   3. 在代码模型里模拟输入，观测输出；如在代码simulink模型中搭建测试module；

      1. 导入测试用例：首先要制定测试用例，以SWE.3中的模块为例，制定测试case；

         SWC	Test ID	测试人	前置条件	用户输入	功能预期	实际测 试结果	功能通过 (Y/N)
         LoBeam	Unit-test-01	**	PowerSts =ON	LightsWSts =LoBeamON	LoBeamReq= Req
         LoBeam	Unit-test-02	**	PowerSts =OFF	LightsWSts =LoBeamON	LoBeamReq= NoReq

      2. 执行测试：按照测试case执行测试代码+功能代码，记录测试结果；

      3. 针对测试结果及覆盖度结果补充测试用例：分析测试结果，同步的检查测试用例制定的完整性

      4. 回归测试：反馈测试NG项，待代码修改后回归测试，完整的流程过程物/输出物应该还包含详细的测试计划、测试报告分析等内容。

5. SWE.5：软件组件验证和集成验证；这一环节目的是验证软件组件与软件架构设计一致，并集成软件元素，验证集成的软件元素与软件架构和软件详细设计一致。开发工程师应遵循以下BP进行进行验证：

   1. 指定软件集成验证措施
   2. 指定验证软件组件行为的验证措施
   3. 选择验证措施
   4. 集成软件元素并执行集成验证
   5. 执行软件组件验证
   6. 确保一致性并建立双向可追溯性
   7. 总结和交流结果

   SWE.4与SWE.5均是做软件验证，区别就是范围不一样，SWE.4侧重于单个软件单元的验证，确保单元的正确性和质量；而SWE.5则关注于软件组件的集成和整体系统的测试，确保系统能够正确运行并满足需求。

   

   SWE.5的关键输入即是SWE.2中的输出物–软件架构；软件集成后，按照SWE.2中SWC模块逐步进行测试即可；测试过程与相关过程物类型与SWE.4接近。

6. SWE.6:软件验证；确保集成的软件与软件需求一致，也叫软件合格性测试。开发工程师需要遵循以下的BP来进行实现：

   1. 规定软件验证的验证措施
   2. 选择验证措施
   3. 验证集成软件
   4. 确保一致性并建立双向可追溯性。
   5. 总结并沟通结果

   该环节的输入主要来源于上级SYS.1中的系统需求与SWE.1中的软件需求；SWE.6与SWE.4、SWE.5同属测试范畴，为了更好的区分，特意做出如下对比：

   区别点	SIWE.5：软件集成与集成测试	SWE.6：软件合格性测试
   目的	验证软件组件之间的集成和交互是否满足系统需求	确保集成软件整体符合软件需求
   关注点	软件组件之间的接口、集成顺序、集成环境	集成软件的整体功能和性能，以及与软件需求的符合性
   测试范围	特定于软件组件之间的集成和交互	覆盖整个集成软件
   测试用例 设计	基于集成的功能和需求设计	基于软件需求设计
   输出	集成测试结果、双向 可追溯性、集成测试报告	软件合格性测试结果、双向可追溯性、测试报告

   

   以SWE.1中软件需求SW_REQ-10001为例，验证用例和测试结果记录表格可参考如下：

   软件验证规范	=	=	=	=	=	=	=	=	=	=	=
   软件需求ID	标题	作者	子系统 Subsystem	测试ID	测试人	优先级	前置条件	用户输入	功能预期	实际测试结果	功能通过 (Y/ N)
   SW_RE Q-10001	LoBeam	**	近光灯	SW_REQ -10001-1	**	中	车辆上电	打开近光灯开关	近光灯打开
   :	:	:	:	SW_REQ -10001-2		低	车辆下电	打开近光灯开关	近光灯未打开
   :	:	:	:	SW_REQ -10001-3		中	**

[!important]

双向追溯:

1. V模型左边的需求、设计和实现之间
2. V模型左边的需求设计实现与V模型右边的测试规范（或测试用例）之间
3. 测试用例与测试结果之间
4. 变更与变更影响的工作产品之间