您好,欢迎来到中国汽车电子电气架构发展论坛2021!

汽车电子软件过程质量保证工作的上天和落地

发布日期:2020-08-09

GRCC 汽车电子电气架构创新发展论坛 前天 

手机阅读



点击上方蓝色字体,关注我们

此文不会论述过程质量具体的保证办法,仅仅根据遇到的问题谈一下“落地”的方法。如果对软件质量感兴趣的朋友,可以加公众号,我会定期分享更多关于软件质量的想法


作为一名在汽车电子软件行业厮混多年*终“样样通样样松”的带有苦口婆心灌鸡汤技能的“教练型”质量经理,经历过程序猿,架构师,测试,集成工程师,QA,敏捷教练的角色洗礼,无数或大或小的坑,挖过,见过,填过......

如今天道循环,做了质量工作,眼前“山高路远坑深,BUG纵横驰奔”,唯有横刀立马,抽丝剥茧,进要评审测试看LOG,退要验收评级灌鸡汤,上要推进过程建设,下要制定改进方案。

回首望去,软件质量保证到底靠的是什么呢?

有人说是靠标准过程,现代软件工程的根本目标就是要让软件产品像工业化流水线一样,在每个环节都有标准操作办法,照章办事即可重复获得成功的软件产品。

有人说软件核心是人,是peopleware,要靠**沟通,快速反应,发挥智力和创造力极限,快速满足客户需求。

前者重视流程制度建设,对组织治理和支持能力要求高,讲究逐层分解,分步验证,始终致力于保证一致性。代表就是RUP开发方式。

后者重视个人创造性,对团队协作沟通要求高,讲究**迭代,逐步完善。代表就是敏捷。

汽车电子软件开发应该倾向于哪一种呢?

先来看一下汽车电子软件开发的特点:

  • 硬件强相关。因为车规级要求对硬件验证要求极高,各种实验耗时较长,一般硬件开发周期为1~2年。而软件开发基本要贯穿始终。

  • 代码量较大,并且因为硬件相关性,复用度也较低。

  • 软件变更可能会导致硬件变更,参考第一条,对变更天生排斥。

  • 软件集成环境复杂,可能涉及到多方合作开发,依赖,制约条件极多,关键路径难以识别。

  • 软件的资源消耗限制极多,性能要求极高

  • 稳定性,异常恢复要求高。

较长的开发周期决定了一定要在早期对需求进行充分了解,架构充分考虑,否则后期的变更成本极高。

由于汽车智能化的发展,“互联网造车”兴起,上述的汽车电子开发开始有了新的变化:

  • 因为功能更加复杂,软件比重越来越高,软件公司开始扮演更重要的角色。

  • 竞争更激烈,产品周期必须缩短。

  • 军备竞赛,新功能层出不穷,在以年为单位的开发周期中,可能会经常迭代新功能。

  • 软件集成更加复杂,需集成移动互联网的内容商。

  • 生态逐渐建立,APP快速迭代也成为了可能,OTA更是成为必须要有的卖点。

“手机化”的汽车智能进程中,软件开发也必须快速迭代来适应。

所以今天,汽车电子软件的开发是应该结合传统的开发流程,初期做充分的需求分析和架构论证,以减少后期因考虑不周带来的硬件调整成本。过程中辅以阶段性迭代,来快速验证阶段工作,提前识别风险,渐进细化功能实现。

下面是Tony老师整理的汽车娱乐系统开发周期的阶段交付物,在敏捷环境下,设计和开发过程中的主要交付物都应该是通过迭代来实现渐进明细的。


以上论述都是基于汽车电子导航娱乐系统的,动辄上百人团队来实现。

但是一些其他传统的部件,因为OTA要求,互联化要求,软件开发同样面临新的挑战。但这种开发团队可能只有1~2个软件工程师,如何来使用上述的庞大的开发要求呢?

我们带着问题来看什么是软件质量。

------------------------我是分割线--------------------------------------------------


个人认为,软件质量体现在以下3个维度:

功能质量: 软件实现的特性(包括功能,性能,资源限制,用户使用方式,合规,安全等等)满足需求的程度。通常以qulification testing的方式来*终评估。

结构质量:软件源代码级别的质量。包括程序代码的健壮性,复用性,可移植性,高内聚低耦合,open for extention,close for modification等。通常使用静态测试,单元测试方式来评估。例如使用工具来评估源代码的潜在缺陷,MISRA符合度,圈复杂度,调用深度等等。 再例如通过单元测试的分支覆盖度,路径覆盖度等衡量被测试的程度。

过程质量:生产软件的过程能够被证明软件成功生产不是偶然的,换了另外一个团队,依然能够复制这种成功。这也是项目管理过程的基本思路。

我们这里只着重说一下过程质量。

大家都听过CMMI,Automotive SPICE

--------------插播广告:本人有丰富的ASPICE忽悠经验,深入的实操经历,承接各种培训,教练工作。广告结束-------------

核心目的,是按照已被证明成功的过程模型,结合组织实际情况,定义*符合项目团队的开发方式,进而归纳为组织级别的制度,使组织能够高效投放资源,保证项目质量。

所以前面说的开发生命周期里的每一个步骤,都体现整个团队乃至组织的能力。

我的主要工作之一,也是通过对潜在合作伙伴的历史项目实施情况,组织的治理策略等来判断其能否成功实施项目,成功的几率有多大。

这就是所谓上天,以从上到下的视角,全盘考察,判断组织能力,识别风险。

而前面提到的极小的开发团队,显然无法具备综合的质量保证能力,(当然,再大的团队也同样会有资源不足的问题)那么如何在制约条件下,充分使用有限资源,剔除低效过程,无限**的直击开发风险,这就是使用过程质量的方法论去解决实际问题,也就是落地。

听起来有点玄,举个简单的例子。

找老婆,灵魂沟通,传宗接代(只适合大龄单身的方法论,我这种少年就私定终身的不在讨论范围内)。 首先要综合候选人的样貌,家庭,教育程度,礼仪,身材,智商情商等等等等给出评分。但是真正做决定的过程中,还是要照好镜子,晃晃自己有多少墨水,看看三个钱包里的银行卡余额(国家帮大家算好了是6个钱包,因为单身所以3个),看看称上的数字(这些就是制约条件),所以要解决*核心,*痛的需求,只能裁剪标准,把有限的资源投入到无限**的定向撩妹中去。

---------------------我是分割线-------------------------------------------------------------------

接着说落地过程中的难题,*近跑了很多简单控制器厂商,发现其软件开发有如下特点:

  • 生产为主,软件开发一平台适配所有产品。软件开发大部分只是修改配置。

  • 软件开发人员数量少,通常一个项目1~2个人即可搞定。

  • 组织分工简单,一般只有软件开发人员,兼职需求工程师,开发测试工程师,QA工程师,测试工程师等。

  • 测试团队并没有软件功能测试过程,多是整个产品的功能测试。

  • 软件人员工程素养和平均水平和纯软件公司相比较低, 没有歧视,因为企业利润来源不是软件,软件团队资源获取较少,工程师工作范围较窄,提升有限。 当然也不排除有大神。

  • 工具使用有限。因为资源有限,很少有系统的使用工具链来提高工作效率的。

所以在审核的过程中,会发现拿着锤子结果发现没有钉子去砸的无力感,就一个人写代码,我要怎么跟他讲过程质量?大部分要求都会被“我就一个人,你说的都对,但是我要是去做你说的那些,进度怎么办”怼回来。

怎么办?过程质量还要吗?

我的办法还是按照上面说的“落地”,抓住主要矛盾,裁剪标准要求,尽可能把有限资源**的投入到*大的风险处理上。

这种软件开发环境下的主要风险是什么:

需求分析:


  • 缺失专门的需求分解过程和详细的WBS及任务分解,收到需求后第一反应以平台实现去配置,很容易忽略掉定制化的需求

  • 对性能要求考虑不周,导致后期更改成本增加,或者验收时无法通过

  • 功能的可行性分析,验收标准,制约因素,实现顺序,依赖关系等等识别不清。

  • 变更管理,追溯性不好。无法有效的对后续变更做影响分析。

举例:

客户需求里有OTA要求,平台产品支持此功能,工程师认为此功能没有问题。

但是工程师并没有跟客户确认是否要支持bootloader的自升级,个人认为是不需要的。 当前系统的ROM使用量已经超过70%,如果后期确认是需要的,那么基本上ROM空间就不够用了。

这就是典型的客户需求分析不够细致,并且没有引导客户需求,没有和客户达成一致的案例。

当然,多说一些,需求分析是接触到的所有供应商的通用软肋,作为供应商,受到成本,进度的制约,都是想马上开始开发工作,尽快交付。 先做起来,遇到不清楚的再问。实际上,各个系统功能都是互相依赖和制约的,不从全盘考虑,会漏掉很多设计元素,而这些都极有可能在后期爆发出来。

而作为客户,老子找了那么多攻略,实地考察那么久,问了那么多人,就来你家为的是吃一口卤煮,老子花了钱的,你直接给我拿你*地道的东西出来就行了。什么,还要我写好大肠是要82年还是85年的猪?花猪还是黑猪?我他妈知道我不就自己干了,来你这干啥。

客户是希望供应商能够凭借其在专用领域内的先进经验,来引导我的思考,确定我真正要的是什么。 你得给我讲花猪和黑猪的大肠有什么区别吧。

软件设计和编码:

  • 设计和编码通常由1~2人完成,个人能力决定质量。这在工程学里是很可怕的事情,不是不相信个人能力,只是害怕没有交流没有多方验证带来方案和代码的不确定性。 根本上讲,就是我选的是你的公司,但是不是选择的你。如果这一切都是由你来完成,没有组织级的支持和验证,这是不可信赖的。

  • 静态测试缺失。只会有一些编码规范定义,也无法使用工具检查。无法保证源代码的质量。

  • 单元测试缺失。昂贵的单元测试工具几乎不可能出现在这种环境下。

  • 对需求对应的设计要素,软件模块的优先级排布,实现计划等缺失。 因为一个人,除了对交样节点承诺的功能负责外,几乎不会给自己定义功能的实现计划,在每个功能的投入是看天和心情的。

  • 问题解决,方案变更等处理无法及时响应。 

  • 一般缺少代码管理,做得好的用SVN,Git。 甚至有直接本地开发,只有交付时提供软件包的,完全没有基线,变更追溯的管理。如果人员离职,电脑损坏等意外,整个项目就要停摆。

  • 方案和代码的演化是个人行为。 工程师可能因修改问题持续反复的调整算法,配置等内容,但是并没有指导方向和监督。*后交付的内容,没有可解释性和追溯。 人员离职,换人之后完全无法理解当前的软件。

举例:

某供应商重要软件模块只给提供1位工程师,这个模块所有问题都只能靠他来解决,遇到一个解决一个。问题原因,解决方案,归纳,排查等完全没有,且工作负担极大,导致客户都心疼他,怕他受不了跑路。他的所有方案,都是他个人能力体现,而不是组织能力体现。

测试:

  • 开发过程中的测试是无法得到保证的。同时,一般只会在交样之前提交测试,发现问题修改和回归都比较紧张,无法保证交付质量。

  • 测试团队会偏重于基于平台经验测试产品通用特性,而忽略具体产品的定制特性。

  • 测试问题以文件记录,无法形成有效闭关跟进。

举例:

某供应商测试问题以文字描述形式列在测试报告中,发给软件工程师。 软件工程师修改之后自己验证。 

问题的原因分析,总结,回归验证等等,完全缺失。

灾难的支持体系:

上面仅仅从需求,设计编码,测试角度举例说明,而质量保证,项目管理,变更管理,配置管理,交付等等支持体系更加无从谈起。


通过*近对此类开发团队的考察和沟通,针对上述问题,大概列一下重点的关注点,欢迎大家来指正。

需求:

  • 识别平台支持和定制化需求,分析后者可行性并得到客户确认。 

  • 需求分解到任务级别,得到客户确认。

  • 保证客户输入得到管理,保证一致性和追溯性。

  • 定义验收标准,得到客户确认。

设计编码:

  • 同行评审。

  • 代码和文件的基本工具链支持。

  • 基线管理。

  • 任务实现计划,个人工作计划。

  • 软件部门对项目的支持和质量管理。

  • 引入代码检查工具。

测试:

  • 明确的用例

  • 指定的测试资源

  • 可闭环的问题管理机制

  • 依据开发计划提前制定测试计划并获取测试资源

其他:

  • 变更管理机制

  • 交付物定义,基线管理

  • 软件功能开发计划和交付计划



相关文章

下载 | 汽车电子软件编写规范MISRA_C
深度】车域软件,老牌汽车制造商们面临着的新挑战




SELECTED EVENTS




 

长按二维码识别关注


 

/长按二维码申请加入 EEA 技术交流群/ 


我就知道你“在看”


  • 电话咨询
  • 021-22306692
  • 15021948198
None