ASPICE vs Agile，谁是自动驾驶时代答案？来源|智能汽车设计知圈|进“计

来源|智能汽车设计
知圈|进“计算平台群”请加微yanzhi-6,备注计算
开写前先唠两句，只要与开发工程师多聊两句，你就会很容易地发现，开发工程师几乎是一边倒的支持敏捷开发，笔者曾完整地参与过一次ASPICE认证项目，也在敏捷模式下进行过较长时间开发。从开发工程师的角度出发，使用敏捷进行开发的体验吊打ASPICE(或者V模型)九条街，但我们今天讨论的话题是哪种模式更适合“更快更高质量”地输出产品，而不是哪个模式对工程师更友好。那么我们就来探讨一下这两种开发模式在域控时代的适应性。
当汽车电子电器架构还处于分布式的年代， ASPICE（或V模型）可以说是唯一的答案，就没听说过哪家Tier1或者OEM是使用敏捷去开发一个发动机控制器的。到了域控时代，新的玩家入场，开发逻辑出现不同声音，特斯拉，蔚小理等硅谷/互联网背景出身的新玩家都使用敏捷进行开发，做出来的产品用户体验确实让消费者有种“诺基亚转安卓”的感觉，难道说敏捷就有如此大的魔力？可以给软件赋予生命力？ASPICE和敏捷的差异和思路究竟在哪？
1.ASPICE：堂正之师
1.1.简述
ASPICE的核心思想就是DRIFT(Dothingsrightinfirsttime) ， ASPICE认为：软件缺陷修复的成本是随着软件进度的开展，成倍数级提升的， BUG越早发现，成本越低；
BUG在不同阶段引入的修复成本
在关键控制器上（比如动力总成的ECU），某些Bug可能是致命的（字面意义上的）且难以被发现的，因此，对代码的态度必须慎之又慎；
传统的合作关系上，通常是Tier1供控制器（Turn-keyorCustomer-sharing）， OEM集成到车上，对于软件这种无形的资产，又是闭源交付， OEM管控是很难的，唯一的监管方式就是交付物，所以ASPICE既是开发过程，也是质量证据。
因此， ASPICE讲究走一条最康庄平坦的大道：
一份不偏离相关方（stakeholder）意图的工程需求---->按照意图，考虑所有cornercase ，基于选型芯片资源，设计考虑完备的软件架构---->将软件架构进一步细化到模块与函数级别的详细设计---->与详细设计思路一模一样的编码---->验证是否与详细设计一致的单元测试---->验证是否与软件架构设计一致的集成测试---->验证是否与软件需求一致的合格性测试。
说白了，就是：
V左半边：保证每一行代码都能知道是为哪一条需求服务的。
V右半边：保证每一行代码都在正确的实现每一条需求。
1.2.ASPICE的缺点
ASPICE统治了汽车软件这么多年，自然有他的必要性与优势，但ASPICE的缺点也非常致命：
1.难以拥抱变化
从上文可以看出，一套V模型撸下来，都是一环套一环的，下一步的输出完全依赖上一步的输入，如果需求发生了变更，而且需求还是与原需求互斥的，那整个项目的改动量将是灾难性的。所以有些OEM的DRE可能会很疑惑，为什么看起来一个小小的CR（changerequest）发下去，会被Tier1告知一大笔的开发费用，甚至是拒绝？流程可能就是其中一个原因。只要代码需要变更，好嘛，相应的设计文档作废，重新设计，测试重新做……想想都头疼。而国内的项目氛围又是“最爱”拥抱变化的， hmmm……

文章图片
2.对人力消耗巨大
我贴一下SWE.3（软件详细设计与单元开发）的BP出来给大家感受一下

文章图片
SWE.3BP