V模型 (軟體開發)

系統工程中的V模型

軟體開發中的V模型是一種延伸自瀑布模型的軟體開發過程，是通用V模型的一個例子。V模型的軟體開發不是以直線的方式進行，其過程在原始碼階段之前逐步往下，而在原始碼階段之後逐步往上，形成了V字形。V模型指出了軟體開發中的各階段以及其對應軟體測試階段之間的關係。橫軸表示時間或是專案的完成度，而縱軸表示抽象的程度（範圍越大，越抽象的在越上方）。

專案定義階段

需求分析

需求分析階段是專案定義階段中的第一個階段，有些文獻也稱為是驗證（verification）階段的第一個階段。此階段要分析用戶的需要，整理出系統的需求（功能需求）。此階段著重的是建構出要實現的理想系統，但不用決定軟體的設計方式。一般而言，此階段會和用戶面談，建立用戶需求文件（user requirements document）。

用戶需求文件會說明系統的功能、介面、性能、資料、安全性等，會列出客戶預期的需求。企業分析師會用這個，配合其系統性的瞭解，來和用戶溝通。用戶會仔細的確認這些文件，因為文件是系統設計師的指南，也會在這個階段規劃用戶驗收測試。

在收集用戶需求時，有許多不同的方式，常見的有訪問、問卷、文件分析、觀察、利用可丟棄的原型、用例等。

系統設計

系統設計是系統設計師根據用戶需求文件，分析並理解要開發系統的業務流程的階段。此階段會列出要實現用戶需求需要的技術以及可能性。若有些用戶需求不可行，會反應給用戶，針對此需求的最後處理方式也會列在用戶需求文件中。

此階段也會產生軟體規格文件（software specification document），是開發階段的藍圖，其中會包括大致的系統架構、指令選單結構、資料結構等，其中也會包括業務場景、樣本視窗以及報表以幫助理解。此階段也會產生實體圖（entity diagrams）、數據字典等技術文件，並且整理系統測試的文件。

架構設計

這個階段會設計計算機系統結構及軟體架構，也稱為高階設計。選擇架構的基準是應該可以實現所有模組的列表、模組的簡單機能、介面關係、相依性、資料庫、資料庫表、架構圖、技術細節等。在這個階段也會設計整合測試的內容。

模組設計

模組設計階段也稱為低階設計。會將設計的系統拆解為較小的單元或是模組，也會說明每一部份的內容，讓程式設計者可以直接寫程式。 低階設計文件或是程式規格書會包括模組的邏輯細節，可能會以偽代碼的方式表示，也會有以下的內容：

• 資料庫表，其中有所有的元素、型態以及大小。
• 完整應用程式接口程式的介面細節
• 所有相依性的議題
• 錯誤訊息列表
• 模組的所有輸入及輸出

單元測試會在此階段進行規劃。

確認階段

在V模型中，驗證（或專案定義）階段中的每一階段，在確認階段都會有對應旳階段。以下是V模型的驗證階段，不過也會使用其他的名稱。

單元測試

在V模型中，在模組設計階段就會規劃單元測試計劃（Unit Test Plans）。單元測試計劃的目的是要消除程式碼層級及單元層級的錯誤。單元是程式中可以獨立存在的最小程式體，例如程式模組。單元測試是驗證最小的程式體在和其他程式隔離的情形下，是否可以正常運作。

整合測試

整合測試的計劃會在架構設計階段訂定。整合測試會驗證這些獨立創建、獨立測試過的模組是否可以共存，互相交換訊息。整合測試的測試結果常會分享給用戶的團隊。

系統測試

系統測試計劃會在系統設計的階段訂定。系統測試不同於單元測試及整合測試。系統測試計劃會由用戶的團隊來進行。系統測試會確保所開發的軟體符合預期的需求，會測試整個軟體的機能、相互依存以及通訊。系統測試也會驗證系統符合機能需求以及非機能需求。像負載測試、性能測試、壓力測試及回歸測試等，都是系統測試的一部份。

用戶驗收測試

用戶驗收測試（User Acceptance Test）計劃會在需求分析階段就訂定。測試計劃是由企業用戶來進行。用戶驗收測試會在用戶的環境下進行，設法模擬實際產品的環境，也會使用實際的數據。用戶驗收測試的目的是要確認所提供的系統符合客戶需求，而且系統已可以在實際環境下使用。

批評

敏捷軟體開發倡議者對V模型有所批評，因為以下的原因，V模型不適合作為軟體開發的模型：

1. V模型太過簡單，無法準確的反映軟體開發的過程，會讓管理者有一種錯誤的安全感。V模型反映了軟體開發中，管理者的觀點，適合專案管理者、會計師及律師，但不適合軟體開發者及用戶。
2. 對於新手而言，V模型很容易了解。但新手需要對開發流程有進一步的瞭解，並瞭解V模型在在實務上如何應用及擴展，才能真正的應用V模型。若開發者仍堅持早期對V模型的較不成熟的觀點，很難成功的應用V模型。
3. V模型不太可變，鼓勵在軟體開發上，比較嚴謹及線性的觀點，在本質上比較沒有反應變化的能力。
4. V模型是瀑布模型小幅改變後的版本，因此也有類似瀑布模型的問題。這類模型較強調測試、特別是早期的測試計劃。不過有關V模型常見的批評就是：V模型將測試塞在開發流程後面的時間區間內，有可能早期的專案設計時程已經超過時間，但軟體正式發佈的時間不變，因此就會大幅壓縮測試的時間。
5. V模型較符合一些效率較低、效果也較弱的測試方法，因此潛在的也會鼓勵這種測試方法。V模型較鼓勵事先寫測試腳本，而不是進行探索測試。V模型鼓勵測試者去確認他們預期會發現的項目，不是找出實際的情形。V模型也鼓勵在開發階段及確認階段各對應階段的嚴謹連結（例如，由用戶需求文件產生用戶驗收測試），而不是鼓勵測試者去選擇最有效率、有效果的方式來進行測試。
6. V模型缺乏一致性及準確性。因此許多人會對V模型困惑，不確定其準確定義。若將V模型視為是大多數人認為的那種方法，在軟體開發上旳意義又不大。不同的人可能對於V模型的優點及缺點會有不同的認知，這也反應V模型在某程度上沒有共通的定義。

現狀

V模型的支持者指出V模型也會逐漸進步，在開發過程中也可以有可變性，符合敏捷開發的原則。支持者認為V模型強調紀律、也提倡精細的設計、開發以及文件,這些都是要建構穩定軟體產品時，必要的元素。近年來，V模型已用在醫療軟體的開發上。

相關條目

• 產品生命周期
• 系統發展生命周期

延伸閱讀

• Roger S. Pressman:Software Engineering: A Practitioner's Approach, The McGraw-Hill Companies, ISBN 0-07-301933-X
• Mark Hoffman & Ted Beaumont: Application Development: Managing the Project Life Cycle, Mc Press, ISBN 1-883884-45-4
• Boris Beizer: Software Testing Techniques. Second Edition, International Thomson Computer Press, 1990, ISBN 1-85032-880-3

外部連結

• The SDLC and SixSigma
• SDLC for small and medium DB applications