在做軟件開發時，程序員們肯定接觸過各式各樣的軟件開發模型，例如：寫了再改模型、瀑布模型、增量模型等。其實，很多開發模型是在瀑布模型基礎上衍生出來的。
然而，瞭解“V”模式開發模型的程序員應該不多。“V”模式開發模型是汽車電子行業在瀑布模型的基礎上做了改進，以符合汽車ECU開發需要的模型。
今天來講講瀑布模型與“V”模式開發模型的異同。
瀑布模型
瀑布模型產生的歷史背景是20世界70年代出現的軟件危機，該模型將軟件開發分爲若干階段，由於其類似於瀑布從上到下的過程，故稱其爲“瀑布模型”。
從圖中可以看出，瀑布模型分爲：項目提出及規劃—需求分析—軟件設計—軟件編碼實現—軟件測試—上線運行等6個階段。這幾個階段相互遞進，也就是說本階段完成後才能進行下一階段的工作。
因此，瀑布模型在實踐過程中具有以下侷限性：
-
試圖將各步驟分離，然而這樣嚴格的分離無法實現
-
回溯修改幾乎不可能，但軟件開發需要時間回溯
-
最終產品直到最後一個步驟纔出現，而軟件客戶無法在早期直到軟件原型，可能會引發軟件功能與客戶需求不匹配的情況
在移動互聯網時代，快速搶佔市場纔是王道，如果企業採用瀑布模型開發軟件，根本就無法存活。瀑布模型的上述侷限性導致其已經無法完全適用於互聯網行業的發展。
在我看來，瀑布模型不太適用於開發針對用戶也就是針對“人”的軟件。
然而，作爲軟件工程最先出現的開發模型，瀑布模型還有適用範圍嗎？當然有，比如汽車電子行業所採用的“V”模式開發流程便是遵循瀑布模型進行軟件開發。
"V"模式開發模型
“V”模式開發模型是在瀑布模型的基礎上發展而來的，那麼什麼是“V”模式呢？
該開發模型由於形似字母“V”而得名，但如果只看“V”的左邊便能夠看出是瀑布模型。因此，“V”模式開發模型是將瀑布模型進一步細化。
解釋一下爲何用"V"模型來表示，該模型開發流程仍是：系統需求—軟件需求—軟件設計—軟件編碼—單元測試—軟件測試—系統測試—實車測試等幾個步驟。
但該模型的特點是：
- 系統需求確定後，系統測試工程師便開始寫系統測試用例；
- 軟件需求確定後，軟件測試工程師便開始寫軟件測試用例；
- 軟件設計確定後，軟件工程師便開始寫單元測試；
- 最底層纔是軟件編碼的實現。
也即是說，在軟件編碼完成前，系統測試用例、軟件測試用例以及單元測試用例已經完成。
“V”模式開發流程將代碼實現放在最後一步，即使客戶需求發生變更也能很快做出修改，相比瀑布模型減少了回溯的成本和時間，提高了開發效率、降低了開發成本。
隨着技術的更新，我認爲汽車行業也不會嚴格採用“V”模型，畢竟現在很多車輛已經具備OTA工能。但涉及汽車安全方面的需求，可能還是需要遵循瀑布模型，畢竟車企會在保證車輛安全的前提下，纔會將軟件裝車。
總結
不論是何種開發模型，其最終目的均是爲了保證軟件的開發質量。至於項目中使用何種模型，這需要結合軟件特點以及所在行業共同確定。
ps: 歡迎關注我的公衆號[酷酷的coder]，分享轉行菜鳥程序員成長過程彙總的煩惱和反思.
