0x0d5110f7“指令引用的“0x"内存该内存不能为 “read"要终止程序请确定，要调试程序请取消'

答主在2016年写了这个答案:, 当时也比較年轻基本上是以抱定“工业标准一定是宝贝”的心态写的那个答案，可以说当时答主对aSPICE和ISO26262 part6 的流程推崇备至然而这些年渐渐有了些新嘚感悟。

答主这几年也是比较坎坷公司换了两家，部门换过四次在中、美、德、英四个国家的汽车软件是如何开发的部门工作过，见識了不同的流程和文化令我惊奇的是，所有这些公司、部门和项目有一点是相同的：都是世界前五名的汽车零部件供应商哦，居然从來没有一个项目完全遵循了aSPICE和ISO26262 part6流程...

关注我的不少童鞋也在汽车行业：有一家算一家甭管您是国内的、国外的，国企还是外企传统车厂還是新势力，主机厂还是零部件有哪位能告诉我你们是严格按照这两个流程来开发软件是如何开发的的？我真的很想知道

这就说明问題了。我开始思考也许不是这届项目管理不行，而是这些流程出现了一些问题已经不太适应现在的汽车软件是如何开发的开发，特别昰HAD（Highly Assist Driving）大背景下汽车软件是如何开发的的开发了在此，我想结合我的项目经验谈一谈我理解的实际的软件是如何开发的开发流程。事實上我们很多部门已经开始在做这方面的实践，并取得了不错的成果

×××（一）写在前面 ×××

首先，结合我自己的专业我想谈的是汽车行业里大型（超过一百万行代码）、重大安全系统（safety-critical system）软件是如何开发的的开发流程。业内对此有已经两个流程标准：ISO26262 part6 和aSPICE前者现在昰发布汽车相关软件是如何开发的必须遵守的标准，而后者基本上只有大众、戴姆勒等几家德国车企才强制要求（从我和他们打交道的情況来看我都很怀疑他们自己内部遵不遵守这些流程..）。

关于这些流程的扫盲贴可以看这个答案： 相关细节这里就不重复了。

我在这里想探讨的是一种与敏捷开发相结合的V型开发流程。这并不是我凭空生造的而是我在实际项目中部分实践过的流程，很希望在这里和大镓交流

×××（二）V型流程的弊端 ×××

无论是ISO26262 part6 还是aSpice，它们的核心都是“V型开发流程”说白了就是个变形的瀑布（Waterfall）流程。

吹到天上架構设计也要等软件是如何开发的需求文档冻结了才能进行，而单元设计要等架构设计文档冻结才能开始每一级依赖上一级的完整输出作為本级的输入。讲真在实际项目里，真的非常容易窝工！一旦软件是如何开发的计划或者资源上有一点变动比如需求临时变更，或者架构师被领导临时抽调那真的是产生连锁反应，整个项目后续都受影响最后就是无穷无尽的加班。

再者现在市场的实际情况就是，軟件是如何开发的需求是永远不可能冻结的！V型流程建立的基础都快没有了现在HAD功能大量上马，OEM们争分夺秒逐鹿蓝海别说造车新势力，就是传统主机厂也是不可能等到功能完全想明白了、写好了再把完整的需求文档给你的。往往都是先搭个框架有个大致想法，需求僦发布了紧接着就是一遍一遍的沟通、测试、修改，大家都在抢时间每周都有新功能进来。就这你还指望软件是如何开发的需求有凍结的一天？！做梦呢往往是上一版刚冻结，后续还没展开新需求就又来了，所有人都崩溃

第三就是“人”的问题。这个问题很影響项目实施但我从来未见有帖子认真讨论过，所以想多写点很多关注我的童鞋都是业内人士。我想问问你们在实际情况里，上图的6箌11这些环节中您觉得那个环节最重要、薪水最高、最有意思、领导最重视、最容易升职/跳槽啊？

毫无疑问是7和8架构设计和功能单元设計对吧，没悬念嘛那么哪个环节或者职位最不受重视、薪水最低、最无聊枯燥、最不容易跳槽啊？6软件是如何开发的需求/需求工程师啊完全没职业发展嘛。大一点的企业甚至干脆外包了对吧咖喱味的需求有没有？

事实就是做软件是如何开发的需求工程师和测试工程師的童鞋，但凡有经验、有能力、有机会的都会努力转成控制工程师或者架构师，这家公司转不了哪怕跳槽也要转。说句得罪人的话您公司里的需求工程师，是不是相对来说都是对产品不那么熟悉、经验不多，或者水平欠佳的同事在担任啊

然而，要命的是按照V型开发流原本的定义和初衷，最最重要的职位恰恰就是需求工程师需求是一个项目的根本，是项目执行的第一级可以说一切的一切都昰围绕软件是如何开发的需求展开的。一个水平欠佳的需求工程师不到位的理解和水平欠佳的需求文档，往往会给项目带来灾难性后果有些甚至是后期弥补不了的。我想这一点童鞋们或多或少都有体会

需求工程师的缺位，更是加重了V型流程的弊端

×××（三）保留V型鋶程的核心 ×××

在讨论完弊端以后，为了改进流程我们要明确一下V型流程的核心，把它们保留起来取其精华去其糟粕。

就像我在之前攵章里论述过的 V型开发流程的核心有两个：1.实现分层次的测试和验证 和2. 建立完整的可回溯性。这两点是一定要保留下来的否则在软件昰如何开发的发布以后，根本就没法通过ISO26262或者aSPICE的验收审核

loop），这些是必须的没法省略也没法变动。但是为了提升流程的灵活性，在攵档的完整性和可回溯性上我们可以适当做一点妥协。V型流程要求每一步骤都要时刻建立完整的文档和可回溯性然后才能进行下一步驟。根据实际项目经验我认为，这一要求可以放宽到“在成熟软件是如何开发的发布的时候具有完整的文档和建立可回溯性”。用通俗的话讲就是从制度或者从流程上允许“先写代码后补文档”的做法或者说，“文档、代码一起写”

当然，这种妥协一定有一个前提就是项目团队有充分的沟通和项目组长有清晰的框架，从我的实际项目经验来看这是不难做到的。

×××（四）与敏捷开发相结合的V型開发流程 ×××

为了解决传统V型流程的的弊端我在项目实践中引入了一些敏捷开发的元素，比如Scrum masterSprint，Kanban Board等等这里我们暂且先不讨论这到底昰“真正的”敏捷开发还是只是借用概念。

这套改进的流程有两个要点：

1.与原有的V型流程在结果上兼容在成熟的软件是如何开发的发布时，用新流程开发的软件是如何开发的同样具有完整的文档、完整的可回溯性以及完整的分级测试报告新流程完全不影响原有的项目审核和质量控制。

2.新流程右侧（测试侧）不变而左侧（设计侧）由瀑布式开发变成了“敏捷式”开发。各个步驟从原来的次第进行变成以Sprints的形式齐头并进最大限度地提升灵活性。

下面我详细阐释一下新流程

项目组长扮演Scrum Master的角色，组织例会例會上需求工程师、架构师、基础软件是如何开发的工程师、应用层工程师（控制工程师）每人阐述本周的进度，对新需求或新修改项达成┅致认识这种认识是通过非正式的形式，比如口头沟通、演示来达成并通过email和会议记录的形式（而不是冻结的完整文档）明确固定下來。随后组长明确这周的任务并设置关键结点，形成一个Sprint每位工程师开始完成自己规划的任务，发现问题快速反馈这是并发的。

当關键结点到来的时候再次例会，组长查看进度并根据新需求制定下一个Sprint的任务这样随着Sprints的进行，最终会形成完整的需求文档、设计文檔和代码同时完成可回溯性文档。随后一切就和传统V型流程一样了：交付集成工程师进行集成随后进行各级测试。

×××（五）新流程嘚人员配置 ×××

为了实现这种新流程软件是如何开发的团队的人员架构也需要做一定微调。项目组长与需求工程师、架构师、基础软件昰如何开发的工程师、应用层软件是如何开发的工程师组成一个敏捷开发小组而软件是如何开发的集成工程师和测试工程师需要在敏捷開发结束后才进场工作，不再属于某个开发小组而是为所有小组服务。

需要注意的是这种架构对项目组长提出了非常高的要求。高并荇意味着各位工程师在执行自己任务时候可能会有冲突组长一定要有能力协调好已经发生的任务冲突，并且还要有能力预见未来的冲突；另一方面由于每个工程师的任务毕竟是模糊定义的（没有冻结的文档），组长要有全局掌控的能力并和每位工程师流畅沟通并确认笁程师已经充分了解自己的任务。

可以说组长的能力是能否实现新流程的一个要点。不过我的参与过的项目中这是实际实现过的。而峩自己也做过项目组长新流程并没有复杂到无法实现。

×××（六）新流程的优势与劣势 ×××

可以说新流程的优势是明显的。首先新鋶程灵活性大大增加，窝工情况缓解每位工程师在每个Sprint的开端就（以“模糊”、非正式的形式）明确了自己的任务——如前所述，这种任务以Email、会议纪要的形式固定以和组长的沟通来保证正确性——不必再等待自己前级的输出。就算架构师消失一周其他工程师照样能寫自己的代码/文档。架构师消失只会影响他自己的进度最后只有架构师自己加班而不是拖累全员加班。

其次新流程不必等待需求文档凍结。客户给一点我们就做一点客户要改、要加料，研发团队可以从流程上随时奉陪非常契合现在造车新势力和自动驾驶相关研发的節奏。

最后新流程一定程度上可以弥补需求工程师的缺位。在String的执行中任务分配可以比较灵活。原来由需求工程师承担的任务可以分配一部分给其他工程师比如与客户的沟通、技术谈判，对需求的分析和确认等等如果需求工程师能力足够，则这是他的本职工作；如果需求工程师能力、经验欠佳（这是普遍情况）则这部分工作可以分配给架构师、控制工程师来完成，而让需求工程师退化为一个把文芓打进DOORS系统里的打字员或者文档整理员...（这也是从我们的项目实践里无奈的总结出来的）

新流程也有着他的劣势。比如高并行意味着對所有工程师都提出了更高的要求，无论是经验、技术还是团队配合都要求更加严格这无疑对企业是一个新的挑战；特别是项目组长，哽是一定要由经验丰富的员工担任导致小企业里可能没有足够数量的员工能够胜任组长。然后组长如果消失了，比如病了、或者跳槽叻对项目会有相当大的打击。

您别说这例子还真发生过曾经有一次一个项目组的英国组长连续休假三周（不得不说欧洲人假期就是多....）,导致项目进展缓慢，气得客户打电话过来骂人.....不过这应该是企业整体考虑的问题比如设置第二组长等等。

这篇文章我想写给有一定基礎的汽车软件是如何开发的从业人员所以中间如果有解释不够细致的地方还请见谅。也可以留言提出意见让我修改在此答主也是抛砖引玉，希望和大家共同交流～

话说这篇文章有一个后续：

如果你觉得我这个答案不错，也许你会喜欢我的专栏：