ASPICE评估时,SYS相关过程范围的选择

发布于 2023-6-15 18:52
浏览
0收藏

前言:

本周对某个项目,基于ASPICE要求做了一次阶段性检查。项目是在Base基础上,增加了一个功能,硬件没有变化,只是软件的一些模块有了新增和变更。在这几天的工作中,和项目团队讨论了SYS相关过程,也了解到项目团队的迷惑点,故将讨论内容进行整理,形成如下文章。


越来越多的公司想通过ASPICE评估结果,向市场和客户展现自身的过程能力。

说明:如果只是想获得一份评估报告或评估通过证书,而不是想切实提升组织或项目的过程能力,是一种买椟还珠行为。


在确定ASPICE评估的过程范围时,是否选择System相关的过程,以及这些过程的实施要求,是本文的讨论内容。

什么是System

ASPICE模型中,“系统System”的定义是:

完成特定功能或一组功能的由组件构成的一个集合,系统由不同学科构成,如:SW、HW、电子、机电一体化、机械零件等。


单独的SW,或单独的SW模块,不能称为”系统(System)”。


汽车E/E领域相关的行业规范中,System的定义基本都是如此。如:汽车功能安全ISO26262中,对“系统System”的解释如下,读者可以参考。

ASPICE评估时,SYS相关过程范围的选择 -汽车开发者社区

什么情况下可以选择System相关的过程(SYS.2,3,4,5)?

满足如下两个条件时,可以选择System相关的过程:

  • 项目交付的产品,是一个“System”。
  • 项目中实施了与 “System”相关的系统需求分析、系统架构设计、系统集成测试、系统测试等活动。


接下来基于一个特定场景,讨论项目中实施SYS相关过程的话题。

场景

  • 项目交付的产品是一个“控制器”,包含硬件和软件。
  • 项目是基于Base进行的开发,在Base基础上,增加了一个功能。

SYS.2系统需求分析 / SYS.5 系统合格性测试

如下图所示,系统需求分析活动时,分析:

1)在Base基础上,需要有哪些变化:新增了哪些需求,更改了哪些需求,留用了哪些需求。

2)这些新增/更改的需求,对系统的外部接口有没有影响(对运行环境的影响分析)。

说明:本示例中,假设新增/更改的需求都和与“Other System 1”的外部接口有关系,但现有的接口可以满足要求,不需要做更改。

ASPICE评估时,SYS相关过程范围的选择 -汽车开发者社区

如下图所示,系统需求分析后,基于系统需求分析结果,确定项目范围。

项目范围中包括项目测试策略(或测试范围)

ASPICE评估时,SYS相关过程范围的选择 -汽车开发者社区

项目交付的是“控制器”产品(项目对产品的质量负责)。


系统合格性测试:

Reused类型的需求,需要测试还是不需要测试呢?如果不测试的话,不测试的理由是什么?


这个问题留给读者思考。

SYS.3系统架构设计 / SYS.4 系统集成和集成测试

通常情况下,系统架构设计是把系统需求分到不同学科(如:软件、硬件),明确不同学科的分工。


有些组织中,软件部分包括有两个比较独立的团队,APP软件和底层软件。这种场景下,系统架构设计可以把系统需求分配到硬件、底层软件、APP软件三个部分。


下图所示的是Base的系统架构:

ASPICE评估时,SYS相关过程范围的选择 -汽车开发者社区

在Base架构的基础上,进行系统架构设计(如下图所示):


1)为了满足“变更的系统需求”,需要HW、底层软件、APP软件如何来协作和交互呢?

2)HW、底层软件、APP软件之间的哪些接口与这些“变更的系统需求”相关呢?

3)HW、底层软件、APP软件之间的与“变更的系统需求”相关的接口,需要变更吗?

说明:本示例中,假设HW、底层软件、APP软件之间的与“变更的系统需求”相关的接口,都不需要做更改。

ASPICE评估时,SYS相关过程范围的选择 -汽车开发者社区

虽然HW、底层软件、APP软件之间的接口不需要做调整,但这个结论是通过“系统架构设计”活动得到的。


项目是需要实施“系统架构设计”活动的,SYS.3可以纳入评估范围。


接下来考虑”SYS.4 系统集成和集成测试”:

  • HW、底层软件、APP软件之间的与“变更的系统需求”相关的接口不需要变更,那么这些接口,需要进行集成和集成测试吗?
  • HW、底层软件、APP软件之间的与“变更的系统需求”不相关的接口,需要进行集成和集成测试吗?


这样的问题,没有唯一的、正确的、标准的答案。

这样的问题的答案,不是ASPICE评估师决定的。

是需要项目基于“活动实施与否”与“项目交付产品的风险”进行的权衡考虑。


SWE.1 ~ SWE.6的过程,也可以采用如上的方式进行分析,本文不做赘述。

结束语

很多公司都想投入最小的工作量,来让项目达到ASPICE CL-2/CL-3。

经常会问的问题:

  • 只测试变更部分,是不是能满足ASPICE要求?
  • 底层和硬件之间的接口都没有变化,还需要做系统架构设计吗?
  • ……


我的建议是:

  • 进行ASPICE评估的项目,一定是一个“真实”的项目。
  • 真正从满足项目目标(质量、成本、交付)的角度考虑如何来实施项目中的各个活动。
  • 不要为了评估而评估。


推荐阅读:


文章转载自公众号:仨人谈起


分类
标签
收藏
回复
举报
回复
相关推荐