太多人在講V模型了，但越是司空見慣的概念，似乎越讓人難以達成共識。這篇文章給出我的觀點。
開發模型其實有很多，比如，增量式、原型式、螺旋式、噴泉式、W模型等。限于篇幅且必要性不大，我們不講那么多。
其實，能夠反映最基本工程邏輯的模型就是瀑布，包括V模型在內的其他模型大多是以瀑布為基礎來衍生的，或多或少也都能看到它的影子。
我們先從瀑布說起。
1瀑布模型是一種認知邏輯
瀑布模型是大家聽得最多的，也是具備最樸素的認知邏輯的一種模型。
瀑布模型，顧名思義，就是像瀑布的水流一樣逐層推進。
簡單來說，就是在需求、設計、測試3大基礎板塊上的擴展，各項工程活動就像多米諾骨牌一樣按次序排布，并逐層驅動直至最后一塊骨牌倒下。
這種方式雖然簡單，但非常易于理解，所以也便于管理。對于標準化、規范化要求比較高的領域，更是極具友好性，就像汽車制造，就是非常典型的瀑布。
一個簡單的、單一的軟件模塊的開發，如果需求描述清晰、設計方式確定、測試用例明確，最佳的辦法也就是一波流的瀑布。
當然，不是像一串珠子一樣的單向、單通道、串行模式才是瀑布。即使是最簡單的一個機械件開發，也會有并行、來回反復修正的過程。
總體的，我們可以總結瀑布在廣義上的兩個特點：
在時間線上線性串行。
后序輸入需要依賴前序輸出。
這樣，我們會發現，瀑布不單是一種開發模型，也是一種無法跳脫的思考方式。
2V模型的本質
然而，世間規律并非總是完美如12345這樣的次序。當我們面臨具備一定復雜性的系統和合作環境時，最基礎的瀑布模型就不便于我們參考了。
身處冗長供應鏈和擁有復雜機電軟硬一體系統的汽車，就面臨了這樣的問題，基于瀑布而演變的V模型就逐漸成為汽車行業應用最廣的模型。
諸如ASPICE、26262、21434等行業內各種體系標準也都是基于V模型搭的架構。
2.1層層嵌套的汽車V模型
V模型習慣被認為是軟件開發的一種模型，但對于汽車軟件，顯然無法獨立談軟件。
我們不妨按照系統工程的方式理解一下，當俯瞰整個汽車的設計開發時，會發現就是一個個大V模型套小V模型的架構。
首先，多個整車V模型會作為背景板來支撐汽車整體開發架構，并進而支持整車屬性定義、造型設計、架構設計、需求拆分、子系統實現、樣件交付、整車集成、整車驗證等整車里程碑目標的達成。
接下來，一個個ECU子系統的開發再通過多個小的ECU V模型來不斷推進。
進一步地，每一個ECU子系統還能劃分為機械、軟件、算法、標定、硬件、子系統集成等學科領域，而它們也是通過更下一級的小小V模型來運轉。
伴隨著不斷的V模型的迭代，零部件、子總成、功能域系統、整車逐漸成熟，直至整車SOP。
2.2V模型的內核
那么，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模型的內核思路，至少在目前，它依然是我們認識、理解汽車軟件的基礎。
完
原文標題:汽車軟件開發V模型的本質
