ASPICE实施的点滴经验分享-电子发烧友网

近日一直有朋友让写些 ASPICE 的文章分享，不知从何下笔来描述，今日就 ASPICE 实施的点滴项目经验做些分享。

随着 IATF16949 版本发布和软件定义汽车概念的提出，ASPICE 在行业内的应用也越来越普及，加上汽车行业不同的研发标准（如：ISO26262 和 ISO/SAE21434）的应用要求，大家在导入 ASPICE 的过程中随之也有不同的问题产生。

ASPICE 这个单词估计大家已有所了解，其准确的英文描述为Automotive Software Process Improvement and Capability dEtermination 汽车软件过程改进和能力评定，是基于 ISO/IEC TR15504 国际项目而来，ASPICE 是在 Automotive SIG 里的 OEM 厂商，采购论坛和 SPICE 用户小组的共识下于 2001 年启动“Automotive SPICE” 计划，对现有标准在汽车行业的应用和调整。从 2001 年开始到现在历史发展如下图，现在在用是 V3.1 的版本，且在 2021 年发布了 ASPICE for Cybersecurity 模型，ASPICE V4.0 版本的标准在起草中，未来会包含硬件及机械等研发过程。

从上面不难看出 ASPICE 模型涵盖的研发领域越来越广，大家接下来面对的挑战也会更大。今天先从下面几点和大家做些 ASPICE 实施的分享：

一、基于评估目的考虑

从名字可以看出 ASPICE 最初用于软件开发并包含整个系统的过程改进模型，并用于对汽车系统开发中的软件过程能力进行一致性评估，评估结果用于：

总能听到有人说关于 ASPICE 实施流程过重，项目来不及等情况。根据 ASPICE 评估的目的，企业可以根据自己需要来策划实施 ASPICE的重点。如果是客户要求或者认证评估的目的，因为有范围和目的能力等级要求，基于过程模型还是有基本的符合性要求在，实施需要根据标准及客户要求来；但是如果企业参考 ASPICE 过程模型做内部改进，则可根据企业目前的情况和搜集到的数据，针对内部主要的问题及薄弱环节参考 ASPICE 过程模型制定改进计划，进行有的放矢的过程能力提升，这时需要的不一定是 ASPICE 默认的 16 个过程域，例如：企业主要问题在软件需求和单元验证方面，则可从软件需求的完整性，正确性，代码覆盖率，需求和代码评审率等方面制定阶段目标，帮助企业实现内部研发过程的改进，大家可以基于标准但不要被其所限制。

二、项目多标准体系实施

现在汽车研发的标准越来越多，有些公司在实施 ISO26262 或者ISO/SAE21434 流程搭建以及项目文件起草时，文件输出和项目基于ASPICE 的实施是独立的两套过程和交付物，这必然会给项目团队带来人力资源和流程上的重复和浪费。

以ASPICE SYS.2系统需求分析过程为例，要定义系统需求，即使用利益相关方需求及其变更，以识别系统所需的功能和能力。在项目上如有相关功能安全和网络安全的要求，在系统需求分析过程需要考虑以下图所示的相关方（类别包含基于HATA分析得出的功能安全有关需求和基于TARA分析得出的网络安全相关需求），项目需要对整体需求进行管理并按照基本实践的要求进行实施，并非是每个领域的需求单独成文，仅考虑本领域要求进行管控，而是项目的整体需求都需要按照ASPICE需求分析过程的要求执行才能达到需求分析过程的能力要求，例如：要对需求进行优先级排序（对应到发布计划），制定验收标准等。

三、流程实施所用的工具

下面再聊下 ASPICE 实施过程中的追溯和管理工具，关于 ASPICE双向追溯性的要求是比较复杂的，见下图，虽然 ASPICE 没有说工具是必须，但如果没有工具建立和维护这种两个维度的追溯性耗时且耗力，后续更新维护也容易出现错误。公司如有资金预算当然可以采购一些行业通用的工程工具（市面上工具大厂就那几家，当然国内也有一些公司的工具不错）。但如果现阶段没有充足的预算，在需求规模不大的情况下也可以用表格来实现追溯关系，当然也看到有些公司研发人员自己开发了一些简易的工具或者方法来从现在的文件上提取出追溯的要素来维护和检查双向追溯关系，也可达到提高效率的目的。

市面上也有一些研发和管理集成的工具可以帮大家管理研发流程，工具通常有内置的流程导航，报告，统计等功能，帮助大家实现流程管理的自动化，减少在导入 ASPICE 等流程时的人力耗费。如下图所示：持续集成和持续构建流水线中进行代码检查及门禁设置，研发数据统计管理，项目状态报告等。通过这些工具可以帮助研发团队快速的完成必要的流程步骤，给到研发团队实施牵引，数据结果能量化团队的绩效和改进方向，极大的减少管理的成本。