太多人在讲V模型了，但越是司空见惯的概念，似乎越让人难以达成共识。这篇文章给出我的观点。  

开发模型其实有很多，比如，增量式、原型式、螺旋式、喷泉式、W模型等。限于篇幅且必要性不大，我们不讲那么多。

其实，能够反映最基本工程逻辑的模型就是瀑布，包括V模型在内的其他模型大多是以瀑布为基础来衍生的，或多或少也都能看到它的影子。

我们先从瀑布说起。

1 瀑布模型是一种认知逻辑     瀑布模型是大家听得最多的，也是具备最朴素的认知逻辑的一种模型。

瀑布模型，顾名思义，就是像瀑布的水流一样逐层推进。

简单来说，就是在需求、设计、测试3大基础板块上的扩展，各项工程活动就像多米诺骨牌一样按次序排布，并逐层驱动直至最后一块骨牌倒下。

这种方式虽然简单，但非常易于理解，所以也便于管理。对于标准化、规范化要求比较高的领域，更是极具友好性，就像汽车制造，就是非常典型的瀑布。

一个简单的、单一的软件模块的开发，如果需求描述清晰、设计方式确定、测试用例明确，最佳的办法也就是一波流的瀑布。

当然，不是像一串珠子一样的单向、单通道、串行模式才是瀑布。即使是最简单的一个机械件开发，也会有并行、来回反复修正的过程。

总体的，我们可以总结瀑布在广义上的两个特点：

在时间线上线性串行。

后序输入需要依赖前序输出。

这样，我们会发现，瀑布不单是一种开发模型，也是一种无法跳脱的思考方式。

2 V模型的本质    

然而，世间规律并非总是完美如12345这样的次序。当我们面临具备一定复杂性的系统和合作环境时，最基础的瀑布模型就不便于我们参考了。

身处冗长供应链和拥有复杂机电软硬一体系统的汽车，就面临了这样的问题，基于瀑布而演变的V模型就逐渐成为汽车行业应用最广的模型。

诸如ASPICE、26262、21434等行业内各种体系标准也都是基于V模型搭的架构。

2.1 层层嵌套的汽车V模型    

V模型习惯被认为是软件开发的一种模型，但对于汽车软件，显然无法独立谈软件。

我们不妨按照系统工程的方式理解一下，当俯瞰整个汽车的设计开发时，会发现就是一个个大V模型套小V模型的架构。

首先，多个整车V模型会作为背景板来支撑汽车整体开发架构，并进而支持整车属性定义、造型设计、架构设计、需求拆分、子系统实现、样件交付、整车集成、整车验证等整车里程碑目标的达成。

接下来，一个个ECU子系统的开发再通过多个小的ECU V模型来不断推进。

进一步地，每一个ECU子系统还能划分为机械、软件、算法、标定、硬件、子系统集成等学科领域，而它们也是通过更下一级的小小V模型来运转。

伴随着不断的V模型的迭代，零部件、子总成、功能域系统、整车逐渐成熟，直至整车SOP。

2.2 V模型的内核    

那么，V模型的内核到底在哪里？有4个点值得关注。

2.2.1 分层分块细化

我们对于不太好搞懂的东西，要掰开了、揉碎了看。就像我们认识物质，一直从分子、原子、原子核、质子、夸克深挖下去才算是多少弄明白点。

2.2.2 高度关注验证确认

汽车及汽车软件的开发涉及大量的各层级的验证。狭义上，就是工程上的测试；广义上，所有的评审、走查、里程碑、审计、试驾都是验证确认的一部分。

2.2.3 分工合作

第一条的可分层细化也是分工合作的前提，反过来，分工合作的模式也影响了系统的层次和架构，这是相互的。就像康威定律所指出的，“产品必然是其组织沟通结构的缩影”。

2.2.4 开始“混沌”

现在的问题在于，划分为不同“层”和“块”的V模型并不是终极解决方案。

汽车行业开发生态与V模型相互成就，V模型在汽车业的蓬勃中也成为骨架。

但随着软件的进入、域化、集中化的演变，系统到组件的层级关系越来越弱化，组件之间的学科界限越来越模糊。

现实工作中，我们经常会矛盾于这是系统需求还是软件需求，纠结于这是软件测试还是硬件测试抑或是集成测试。

分层分块概念的混沌正在变得明显。

于是，解决这种混沌就成为当下的重点，或许还需要一定的时间，再次由乱到治，但这个过程中，并不用太急着去质疑V模型本身的存在意义。

3 全文小结   总结下来，本文给出了3个关键信息或观点：  

瀑布是一种基础的认知与工程逻辑。

复杂的汽车是通过层层嵌套的V模型逐渐走向SOP的。

V模型的特点在于分层分块细化、高度关注验证确认、分工合作，但目前遇到了分层分块混沌的问题。

4 写在最后   混乱之下，我们最容易被概念蒙蔽，大家都喜欢标新立异。   实际上，无论如何，我们走不出工程最本源——瀑布，也离不开V模型的内核思路，至少在目前，它依然是我们认识、理解汽车软件的基础。