开发模型其实有很多，比如，增量式、原型式、螺旋式、喷泉式、W模型等。限于篇幅且必要性不大，我们不讲那么多。
其实，能够反映最基本工程逻辑的模型就是瀑布，包括V模型在内的其他模型大多是以瀑布为基础来衍生的，或多或少也都能看到它的影子。
我们先从瀑布说起。
瀑布模型，顾名思义，就是像瀑布的水流一样逐层推进。
简单来说，就是在需求、设计、测试3大基础板块上的扩展，各项工程活动就像多米诺骨牌一样按次序排布，并逐层驱动直至最后一块骨牌倒下。
这种方式虽然简单，但非常易于理解，所以也便于管理。对于标准化、规范化要求比较高的领域，更是极具友好性，就像汽车制造，就是非常典型的瀑布。
一个简单的、单一的软件模块的开发，如果需求描述清晰、设计方式确定、测试用例明确，最佳的办法也就是一波流的瀑布。
当然，不是像一串珠子一样的单向、单通道、串行模式才是瀑布。即使是最简单的一个机械件开发，也会有并行、来回反复修正的过程。
总体的，我们可以总结瀑布在广义上的两个特点：
在时间线上线性串行。
后序输入需要依赖前序输出。
这样，我们会发现，瀑布不单是一种开发模型，也是一种无法跳脱的思考方式。
然而，世间规律并非总是完美如12345这样的次序。当我们面临具备一定复杂性的系统和合作环境时，最基础的瀑布模型就不便于我们参考了。
身处冗长供应链和拥有复杂机电软硬一体系统的汽车，就面临了这样的问题，基于瀑布而演变的V模型就逐渐成为汽车行业应用最广的模型。
诸如ASPICE、26262、21434等行业内各种体系标准也都是基于V模型搭的架构。
V模型习惯被认为是软件开发的一种模型，但对于汽车软件，显然无法独立谈软件。
我们不妨按照系统工程的方式理解一下，当俯瞰整个汽车的设计开发时，会发现就是一个个大V模型套小V模型的架构。
首先，多个整车V模型会作为背景板来支撑汽车整体开发架构，并进而支持整车属性定义、造型设计、架构设计、需求拆分、子系统实现、样件交付、整车集成、整车验证等整车里程碑目标的达成。
接下来，一个个ECU子系统的开发再通过多个小的ECU V模型来不断推进。
进一步地，每一个ECU子系统还能划分为机械、软件、算法、标定、硬件、子系统集成等学科领域，而它们也是通过更下一级的小小V模型来运转。
伴随着不断的V模型的迭代，零部件、子总成、功能域系统、整车逐渐成熟，直至整车SOP。
那么，V模型的内核到底在哪里？有4个点值得关注。
2.2.1 分层分块细化
我们对于不太好搞懂的东西，要掰开了、揉碎了看。就像我们认识物质，一直从分子、原子、原子核、质子、夸克深挖下去才算是多少弄明白点。
2.2.2 高度关注验证确认
汽车及汽车软件的开发涉及大量的各层级的验证。狭义上，就是工程上的测试；广义上，所有的评审、走查、里程碑、审计、试驾都是验证确认的一部分。
2.2.3 分工合作
第一条的可分层细化也是分工合作的前提，反过来，分工合作的模式也影响了系统的层次和架构，这是相互的。就像康威定律所指出的，“产品必然是其组织沟通结构的缩影”。
2.2.4 开始“混沌”
现在的问题在于，划分为不同“层”和“块”的V模型并不是终极解决方案。
汽车行业开发生态与V模型相互成就，V模型在汽车业的蓬勃中也成为骨架。
但随着软件的进入、域化、集中化的演变，系统到组件的层级关系越来越弱化，组件之间的学科界限越来越模糊。
现实工作中，我们经常会矛盾于这是系统需求还是软件需求，纠结于这是软件测试还是硬件测试抑或是集成测试。
分层分块概念的混沌正在变得明显。
于是，解决这种混沌就成为当下的重点，或许还需要一定的时间，再次由乱到治，但这个过程中，并不用太急着去质疑V模型本身的存在意义。
关注公众号，点击公众号主页右上角“ ··· ”，设置星标，实时获取公众号“水轻言”最新文章。
完
