軟體工程/流程/V模型簡介
V模型表示一個軟體開發過程（也適用於硬體開發），可以被認為是瀑布模型的擴充套件。它不是以線性方式向下移動，而是在編碼階段之後向上彎曲，形成典型的V形。V模型演示了開發生命週期每個階段與其相關的測試階段之間的關係。水平和垂直軸分別表示時間或專案完成度（從左到右）和抽象級別（最粗粒度的抽象位於最上面）。
在需求分析階段，透過分析使用者需求來收集擬議系統的需求。此階段關注於確定理想系統必須執行的操作。但是，它不確定軟體將如何設計或構建。通常，會對使用者進行訪談，並生成一份名為使用者需求文件的文件。
使用者需求文件通常會描述使用者期望的系統功能、介面、效能、資料、安全等需求。業務分析師利用它來向用戶傳達他們對系統的理解。使用者仔細審查此文件，因為此文件將作為系統設計階段中系統設計人員的指南。使用者驗收測試在此階段設計。另請參閱功能需求。
有不同的方法來收集軟方法和硬方法的需求，包括：訪談、問卷調查、文件分析、觀察、一次性原型、用例以及與使用者的狀態和動態檢視。
系統設計是系統工程師透過研究使用者需求文件來分析和理解擬議系統業務的階段。他們找出實現使用者需求的可能性和技術。如果任何需求不可行，則會通知使用者。找到解決方案並相應地編輯使用者需求文件。
生成軟體規格說明書，作為開發階段的藍圖。此文件包含一般的系統組織、選單結構、資料結構等。它還可以包含示例業務場景、示例視窗、報告以供更好地理解。其他技術文件（如實體圖、資料字典）也將在本階段生成。系統測試的文件在本階段準備。V模型也類似於瀑布模型。
計算機體系結構和軟體體系結構的設計階段也可以稱為高層設計。選擇架構的基線是它應該實現所有內容，這通常包括模組列表、每個模組的簡要功能、它們的介面關係、依賴關係、資料庫表、架構圖、技術細節等。整合測試設計在此特定階段進行。
模組設計階段也可以稱為低層設計。將設計的系統分解成更小的單元或模組，並解釋每個模組，以便程式設計師可以直接開始編碼。低層設計文件或程式規範將包含模組的詳細功能邏輯，以虛擬碼形式表示
- 資料庫表，包含所有元素，包括其型別和大小
- 所有介面詳細資訊，包含完整的API參考
- 所有依賴項問題
- 錯誤訊息列表
- 模組的完整輸入和輸出。
單元測試設計在此階段開發。
在計算機程式設計中，單元測試是一種方法，透過該方法測試原始碼的各個單元以確定它們是否適合使用。單元是應用程式中最小的可測試部分。在程序式程式設計中，單元可以是單個函式或過程。單元測試由程式設計師或偶爾由白盒測試人員建立。目的是透過測試函式內每個可能的分支來驗證內部邏輯程式碼，也稱為測試覆蓋率。靜態分析工具用於促進此過程，其中將輸入資料的各種變體傳遞給函式以測試每個可能的執行情況。
在整合測試中，將單獨的模組一起測試以暴露介面中的故障以及整合元件之間互動中的故障。測試通常是黑盒測試，因為不會直接檢查程式碼中的錯誤。
系統測試將比較系統規範與實際系統。在完成整合測試後，下一個測試級別是系統測試。系統測試檢查整合的產品是否滿足指定的需要。為什麼在元件和整合測試之後仍然需要這樣做？原因如下
- 在較低的測試級別，測試針對技術規範進行，即從軟體生產者的技術角度出發。但是，系統測試從客戶和未來使用者的角度看待系統。測試人員驗證需求是否已完全且適當地滿足。
- 示例：客戶（已訂購併支付系統費用的人）和使用者（使用系統的人）可以是具有自己特定興趣和系統需求的不同群體或組織。
- 許多功能和系統特性源於所有系統元件的互動，因此，它們僅在整個系統的級別上可見，並且只能在那裡觀察和測試。
驗收測試是測試的一個階段，用於確定系統是否滿足需求分析階段指定的各項要求。驗收測試設計源自需求文件。驗收測試階段是客戶用來確定是否接受系統的階段。
驗收測試有助於
- 確定系統是否滿足其驗收標準。
- 使客戶能夠確定是否接受系統。
- 讓目標受眾在“現實世界”中測試軟體。
驗收測試的目的
- 根據最初的需求驗證系統或更改。
- 定義驗收標準
- 功能需求。
- 效能需求。
- 介面質量要求。
- 整體軟體質量要求。
- 制定驗收計劃
- 專案描述。
- 使用者職責。
- 驗收描述。
- 執行驗收測試計劃。
- ↑ Clarus 概念操作。 出版物編號：FHWA-JPO-05-072，聯邦公路管理局 (FHWA)，2005
- Roger S. Pressman：軟體工程：實踐者方法，麥格勞-希爾公司，ISBN 007301933X
- Mark Hoffman & Ted Beaumont：應用開發：管理專案生命週期，Mc Press，ISBN 1883884454
- Boris Beizer：軟體測試技術。第二版，國際湯姆森計算機出版社，1990年，ISBN 1-85032-880-3
