V Model、瀑布模型
v-model是一種軟件生存期模型，由Paul Rook在1980年率先提出的，在1990年出現在英國國家計算中心的出版物中，旨在提高軟件開發的效率和有效性，是我們熟知的瀑布模型的一種改進，瀑布模型（Waterfall Model）將軟件生命週期劃分爲計劃、分析、設計、構建、測試和維護六個階段，且規定了它們自上而下、相互銜接的固定次序，由於早期的錯誤可能要等到開發後期的測試階段才能發現，所以帶來嚴重的後果。 v-model就是在這點改進了瀑布模型，在軟件開發的生存期，開發活動和測試活動幾乎同時的開始，這兩個並行的動態的過程就會極大的較少bug和error出現的機率。在v-model中，我認爲一個關鍵詞就是parallel，說起來簡單，卻是v-model的核心。
v-model包含了三個等級，分別是生存期模型，分配模型，功能性工具需求模型，生存期模型回答了“What has to be done?”的問題，闡述了應當實施哪些活動，應當產生哪些結果，諸如此類。分配模型回答了“How is it be done”，決定了在實施活動的時候應該使用什麼方法，功能性工具需求模型回答了“What is used to do it”，採用什麼樣的工具來實現這些活動。所有這些等級中又是由4個子模塊組成的，分別是項目管理模塊(PM)，系統開發模塊(SD)，品質保證模塊(QA)，配置管理模塊(CM)，這些模塊的功能就顯而易見了。
最典型的V模型版本一般會在其開始部分對軟件開發過程進行描述，如下圖所示：
預驗收測試
可行性分析 －－ －－－> 驗收測試
↘ 預系統測試 ↗
需求分析 －－－－－> 系統測試
↘ 預集成測試 ↗
概要設計 －－－－> 集成測試
↘ 預單元測試 ↗
詳細設計 －－－－－> 單元測試
↘ ↗
編碼
單元測試所檢測代碼的開發是否符合詳細設計的要求。集成測試所檢測此前測試過的各組成部分是否能完好地結合到一起。系統測試所檢測已集成在一起的產品是否符合系統規格說明書的要求。而驗收測試則檢測產品是否符合最終用戶的需求。
V模型的缺陷
僅僅把測試過程作爲在需求分析、系統設計及編碼之後的一個階段
忽視了測試對需求分析,系統設計的驗證，一直到後期的驗收測試才被發現。
分析每一種生命週期模型優缺點、利用Internet搜索相關軟件項目所使用生命週期模型並分析特點，從而更進一步的瞭解各生命週期模型的適用背景
1. 瀑布模型：
背景：在20實際80年代之前，瀑布模型一直被廣泛採用的生命週期模型，現在它仍然是軟件工程中應用得最廣泛的過程模型。傳統軟件工程方法學的軟件過程，基本上可以用瀑布模型來描述。
特點：
A.階段間具有順序性和依賴性：必須等前一階段的工作完成之後，才能開始後一階段的工作；前一階段的輸出文檔就是後一階段的輸入文檔，因此只有前一階段的輸出文檔正確，後一階段的工作才能獲得正確的結果。
B.推遲實現的觀點：瀑布模型在編碼之前設置了系統分析與系統設計的各個階段，分析與設計階段的基本任務規定，在這個兩個階段主要考慮目標系統的邏輯模型，不涉及軟件的物理實現。清楚地區分邏輯設計與物理設計，儘可能推遲程序的物理實現，是按照瀑布模型開發軟件的一條重要指導思想。
C.質量保證的觀點：軟件工程的基本目標是優質、高產。瀑布模型的每個階段都應堅持兩個重要做法：
a.每個階段都必須完成規定的文檔，沒有交出合格的文檔就是沒有完成該階段的任務。完整、準確的合格文檔不僅是軟件開發時期各類人員之間相互通信的媒介，也是運行時期對軟件進行維護的重要依據。
b．每個階段結束前都要對所完成的文檔進行評審，以便儘早發現問題，改正錯誤。
總之，瀑布模型胡完全依賴於書面的規格說明。
D．可強迫開發人員採用規範的方法；嚴格地規定了每個階段必須提交的文檔；要求每個階段交出的所有產品都必須經過質量保證小組的仔細驗證。
缺點：
A. 各個階段產生的文檔時維護軟件產品時必不可少的，沒有文檔的軟件幾乎是不可能維護的。
B. 瀑布模型是由文檔驅動的，在可運行的軟件產品交付給用戶之前，用戶只能通過文檔來了解產品是什麼樣的。
C. 由於瀑布模型幾乎完全依賴於書面的規格說明，很可能導致最終開發出的軟件產品不能真正滿足用戶的需要。
2. 快速原型模型
背景：快速原型是快速建立起來的可以在計算機上運行的程序，它所能完成的功能往往是最終產品能完成的功能的一個子集。快速原型模型的第一步是快速建立一個能反饋用戶主要需求的原型系統，讓用戶在計算機上試用它，通過實踐來了解目標系統的概貌。通常，用戶試用原型系統之後會提出許多修改意見，開發人員按照用戶的意見快速地修改原型系統，然後再次請用戶試用……一旦用戶認爲這個圓形系統確實能做他們所需要的工作，開發人員便可據此書寫規格說明文檔，根據這份文檔開發出的軟件便可以滿足用戶的真實需求。
特點：
A. 原型系統已經通過與用戶交互而得到驗證，據此產生的規格說明文檔正確地描述了用戶需求，因此，在開發過程的後續階段不會因爲發現了規格說明文檔的錯誤而進行較大的返工。
B. 開發人員通過建立原型系統已經學到了許多東西，因此，在設計和編碼階段發生錯誤的可能性也比較小，這自然減少了在後續需要改正前面階段所犯錯的可能性。
C. 快速原型的本質是“快速”。開發人員應該儘可能快地建造出原型系統，以加速軟件開發過程，節約軟件開發成本。原型的用途是獲知用戶的真正需求，一旦需求確定了，原型將被拋棄。
缺點：
3. 增量模型
背景：增量模型也成爲漸增模型。試用增量模型開發軟件時，時把軟件產品作爲一系列的增量構建來設計、編碼、集成和測試。
採用瀑布模型或快速模型開發軟件時，目標都是一次就把一個滿足所有需求的產品提交給用戶。增量模型與之相反，它分批地逐步向用戶提交產品，整個軟件產品被分解成許多個增量構件，開發人員一個構件一個構件地向用戶提交產品。從第一個構件交付之日起，用戶就能做一些有用的工作。
特點：
A. 能在較短時間內向用戶提交可完成部分工作的產品
B.逐步增加產品功能可以使用戶有較充裕的時間學習和適應新產品，從而減少一惡搞全新的軟件可能給用戶組織帶來的衝擊。
缺點：
A． 在把每個新的增量構建繼承在現有軟件體系結構中時，必須不破壞原來已經開發出的產品。
B． 必須把軟件的體系結構設計的便於按這種方式進行擴充，向現有產品中加入新構建的過程必須簡單、方便，也就是說，軟件體系結構必須是開放的。
4. 螺旋模型
背景：軟件開發幾乎總要冒一定風險，軟件風險是任何軟件卡發項目中都普遍存在的實際問題，項目越大，軟件越複雜，承擔該項目所冒的風險也越大。軟件風險可能在不同程度上損害軟件開發過程和軟件產品質量。因此，在軟件開發過程中必須及時識別和分析風險，並且採取適當措施一、以消除或減少風險的危害。構建原型是一種能使某些類型的風險降至最低的方法，當然，原型並不能“包治百病”，對於某些類型的風險（例如，聘請不到需要的專業人員或關鍵的技術人員在項目完成前“跳槽”），原型方法是無能爲力的。螺旋模型的基本思想是，試用原型及其他方法來儘量降低風險，理解這種模型的一個簡便方法，是把它看做在每個階段之前都增加了風險分析過程的快速原型模型。
特點：
A. 對可選方案和約束條件的強調有利於已有軟件的重用，也有助於把軟件質量作爲軟件開發的一個重要目標。
B. 減少了過多測試（浪費資金）或測試不足（產品故障多）所帶來的風險
C. 在螺旋模型中維護只是模型的另一個週期，在維護和開發之間並沒有本質區別。
D. 它是風險驅動的。
缺點：
A. 螺旋模型主要適用於內部開發的大規模軟件項目。
B. 除非軟件開發人員具有豐富的風險評估經驗和這方面的專門知識，否則將出現真正的風險：當項目實際上正在走向災難時，開發人員可能還認爲一切正常。
5. 噴泉模型
背景：迭代式軟件開發過程中普遍存在的一種內在屬性。經驗表明，軟件過程各個階段之間的迭代或一個階段內各個工作步驟之間的迭代，在面向對象範型中比在結構化範型中更常見。一般來說，使用面向對象方法學開發軟件時，工作重點應該放在生命週期中的分析階段。這種方法在開發的早期階段定義了一系列面向問題的對象，並且在整個開發過程中不斷充實和擴充這些對象。由於在整個開發過程中都使用同一的軟件概念“對象”，所有其他概念（例如功能、關係、時間等）都是圍繞對象組成的，目的是確保分析工作中得到的信息不會丟失或改變，因此，對生命週期各階段的區分自然就不重要、不明顯了。分析階段得到的對象模型也適用於設計階段和實現階段。由於各階段都使用統一的概念和表示符號，因此，整個開發過程都是吻合一致的，或者說是“無縫”連接的，這自然就很容易實現各個開發步驟的多次反覆迭代，達到認識的逐步深化。每次反覆都會增加或者明確一些目標系統的性質，但卻不是對先前工作結果的本質性改動，這一久減少了不一致性，降低了出錯的可能性。
“噴泉”這個詞體現了面向對象軟件開發過程迭代和無縫的特性。
特點：
A. 開發過程迭代和無縫。
B. 採用面向對象範型之後，維護時間縮短了。
缺點：
A. 面向對象範型本身要求疆場對開發活動進行迭代或求精。