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

随便说几个工作量大到离谱的：
BP3：很多时候模块间交互是很难穷尽描述的，特别是大型软件，应用层，或者高聚低耦做得没那么好的模块，在不同场景，不同条件下，都可能走不同逻辑，整个交互路径都穷举一遍是很难的，画出来的seq图也很难阅读
BP5：每一步的流程都要求这个，做过的dddd（懂的都懂），有DOORS相对好点，用excel去管理这玩意就是个灾难，还感觉没什么卵用
其实每个BP要求的工作量都很大，我做过大概的统计，执行ASPICE的人力需求是不执行的3倍，除此以外，就像我之前说的，这个流程既是开发流程，也是质量证据，属于监管与被监管的关系，繁重的文档任务深深的打击了工程师的积极性。
2.敏捷开发：短平快，拥抱变化
2.1.简述

文章图片
单次sprint流程
敏捷开发的核心逻辑是解构，把软件需求分解成Epicorstory ，通过一轮开发迭代（sprint）实现相应的功能。一轮sprint包含：需求确认->方案制定->coding->台架验证->实车验证->rollingcandidate版本验证->代码合入
敏捷的优点在于：
拥抱不确定性，发生需求变更，那就直接来一轮sprint ，如果还不够，那就来两轮；
出活快，一个sprint的迭代以周为单位；
充分调动工程师积极性，（相对）轻文档，重代码；
2.2.敏捷的缺点
说完敏捷这枚硬币的正面，下面说他的反面。
相比ASPICE或者V模型，敏捷少做的事情：
缺少统筹全局的进行软件架构设计，导致模块很难做到高类聚低耦合，比如SprintA实现的一个功能，其底层模块其实可以被SprintB的某个功能部分复用，但由于SprintA没有考虑SprintB的开发需求，所以该底层模块并不能被完全复用， SprintB可能就要重新开发一个底层模块去覆盖他自己的需求。多轮sprint下来，可能会有重复造相似轮子的情况出现。这样会导致软件比较臃肿，代码量大，执行效率低，且代码质量不高；
缺少集成测试，导致新加的功能可能对已实现的功能有潜在的影响而不能被发现；
由于短平快的特性，很多时候单元测试也不能充分进行，比如动态单元测试；
与FUSA的流程完全不兼容。 26262也好， 61508也好， 34590也好，都是植根于V模型，使用敏捷开发的软件，很难满足功能安全的开发要求，也无法做功能安全分析，无法做FFI 。
3.谁是自动驾驶时代答案？
两种开发流程各擅胜场，也有其出现的背景，在传统汽车时代，各个控制器没有花哨的功能，但要求软件稳定可靠，这种情况下，使用ASPICE或者V模型进行开发无疑是非常正确的。
域控时代的来临，最主要的变化有三点：
功能众多：带来的变化是软件复杂度指数式上涨，相关方众多
产业链合作关系改变：从一功能一盒子，由Tier1软硬件一起交付， OEM负责集成，到所有功能集中在域控， Tier1只提供底软和硬件，应用软件由Tier1 ， Tier2 ， OEM联合开发
【ASPICE vs Agile，谁是自动驾驶时代答案？】电子电气架构演变
我的观点是：ASPICE不适合用于开发智驾域控软件，敏捷相对更合适，但必须根据汽车软件的特点，进行适配
（一家之言，如果有使用ASPICE完整开发过智驾域控到SOP的经验，非常非常欢迎留言探讨）
3.1.为什么ASPICE不合适用于开发域控？
第一， ASPICE下对发生变更的代价是巨大的，因此需要一次把所有功能都定义，设计完美。然而在域控这种软件复杂度下，我不认为有哪个人或者团队可以在项目开发初期，就能一次把所有的需求都定到完美。不完美，后期增改功能，好嘛，又一轮完整的V迭代，所有文档改掉，软件配置管理做版本管理，恐怕需求没开发完，工程师跑一大半了。