2.2六個傳統軟件模型：瀑布、V模型、原型、增量、螺旋、噴泉

2.2傳統軟件模型 瀑布、V模型

瀑布模型

由於瀑布模型規定的軟件開發過程與軟件生命周期一致，因此瀑布模型也稱為經典生命周期模型。

注：瀑布模型一直被用來規范軟件開發活動，很多后續其它模型都是在瀑布模型基礎上的改進。

特點

瀑布模型是一種線性模型，各個階段按照順序依次進行，下一階段依賴於上一階段的結果。編碼處於軟件開發的中后期，體現了推遲實現的觀點，強調需求分析和系統設計的重要性。

瀑布模型以文檔為驅動，每個階段都有與其相關聯的里程碑和可交付產品。每個階段都會產生相應的報告。每個階段結束前都會進行文檔審查，及早改正錯誤。

實際（帶反饋）的瀑布模型

實際使用中，是帶反饋的。

開發過程的后面的總會返回到上一級。例如：總體設計階段發現需求錯誤，則反饋到需求分析階段；詳細設計階段發現總體設計錯誤，則反饋到總體設計階段。

但對軟件的維護則反饋到相應的階段。例如：若錯誤原因在於編碼，則反饋到編碼階段；如果錯誤原因在於設計，則反饋到設計階段；如果錯誤原因在於需求，則反饋到需求分析階段。

缺點

1. 瀑布模型中，各個階段的划分完全固定，階段之間產生大量的文檔，極大地增加了工作量；
2. 由於瀑布模型的開發過程是線性的，用戶只有等到整個過程的末期，也就是編碼和測試完成后，才能見到開發成果，增加了開發的風險；
3. 早期的錯誤，比如需求分析的錯誤或者總體設計的錯誤，可能要等到開發后期的測試階段才能發現，進而帶來嚴重的后果，導致修復錯誤代價的劇增，甚至無法修復；
4. 現代軟件開發通常需要迭代，而瀑布模型是線性模型，不支持迭代，無法適應軟件開發中的變化；最嚴重的是，需求不明確和需求變化是軟件開發中的客觀事實，但由於瀑布模型的線性特征，無法應對需求不明確和需求變化帶來的影響。

適用場景

系統需求明確且穩定、技術成熟、工程管理較嚴格的場合，如軍工、航天、醫療。能保證這些的高質量完成。

V模型（V-model）

是瀑布模型的變種。

在V模型中，處於頂端的是編碼，左側是分析設計階段，右側是測試運維階段。該模型將測試的各個階段和分析設計的各個階段關聯起來，單元測試驗證詳細設計，系統測試驗證總體設計，驗收測試驗證需求分析。

V模型中發現問題

單元測試發現問題

如果在單元測試發現錯誤，則需要檢查相應模塊的詳細設計，修改相應模塊的代碼，並重新進行單元測試。

系統測試發現問題

如果在系統測試中發現錯誤，則需要檢查總體設計，檢查可疑模塊的詳細設計，對錯誤模塊進行代碼修改，然后進行錯誤模塊的單元測試，通過后再次進行系統測試。

驗收測試發現問題

如果在驗收測試中發現問題，則需要檢查系統需求，然后檢查系統總體設計，然后檢查可疑模塊的詳細設計，對錯誤模塊進行代碼修改，然后進行錯誤模塊的單元測試，單元測試通過后再次進行系統測試，系統測試通過后再次進行驗收測試。

原型模型（Prototype model）

也稱為原型化模型、快速原型模型

由於原型構建處於真正的系統開發之前，為了滿足軟件進度要求，要求原型構建過程要快，因此也稱為快速原型模型。

原型

一個部分開發的產品，就是只開發了一部分。

作用

通過這個部分開發的產品，客戶和開發人員能夠對計划開發的產品的相關方面進行檢查，以明確需求或者確定方案的可行性。

原型最終去向

根據原型質量和項目計划，可以選擇拋棄原型或者把原型發展成最終產品。

例

例1 只做出了圖書借閱系統的主要界面
例2 智能家居系統：只做出了少量的室內信息監視和電器控制

原型化的目的

1. 明確並完善需求，通過演示原型實現，如圖書借閱系統中的主要界面；
2. 研究技術選擇方案，通過技術驗證原型實現，如智能家居系統中的部分監視和控制。

原型模型的階段

共兩個階段：原型構建階段、系統開發階段。

原型模型構建階段

原型構建階段開始於策划原型需求，然后構建原型系統，部署原型系統，基於原型系統和客戶溝通，明確需求或驗證方案。如果用戶不滿意，則修改原型需求，修改原型系統，重新部署原型系統，再次和客戶溝通，經過多次迭代，直到用戶滿意，才進入系統開發階段。

系統開發階段

按照正常的開發過程：進行需求分析，設計，實現，測試和維護。

原型模型的優缺點

優點

由於通過構建原型來明確需求，能減少需求不明確帶來的風險

缺點

•由於構建原型要求快，構造原型采用的技術和工具不一定主流

•快速建立起來的系統加上連續的修改可能導致原型質量低下

•設計者可能需要在質量和原型中進行折中，可能產生客戶意識不到一些質量問題

​ ——“如果拋棄原型，則開發時間延長，若將原型發展成最終產品，則系統可能會存在一些客戶意識不到的質量問題。”

適用場合

1、當客戶定義一個總體目標集，但並不清楚系統的具體輸入和輸出

2、開發者不確定算法的效率、軟件與操作系統是否兼容以及客戶與計算機交互的方式等情況

增量模型（Incremental model）

增量

類似於原型，滿足用戶需求的一個子集，是能夠完成一定功能、小而可用的軟件

增量與原型的區別

都是系統的一部分，但是它們的構建原因不同和最終結局不同。

原型構建：明確需求或驗證方案，最終可能會被拋棄

增量：是實際開發過程和最終系統的一部分

增量模型例子：文字處理軟件的功能發布

文字處理軟件：實現三個功能——創建文本、組織文本、格式化文本。依次實現每一個增量到發布的功能的轉變，這時系統所有增量開發完成，系統開發完成。

增量模型開發階段

增量開發1：先對整體分析設計

1. 首先對整個系統進行需求分析和體系結構設計
2. 根據增量的划分，分別對每個增量進行設計、編碼、測試、交付，從而形成每一次發布。
3. 增量的開發允許一定程度的並行，每一次發布都是在上一次發布的基礎上增加新的增量。
4. 當所有的增量開發並發布完成，則形成系統最終產品。
5. 為了保證每個增量都能正確集成到系統中，增量模型要求系統體系結構具有開放式結構。

增量開發2：不對整體分析設計

如果在軟件開發初期無法確定軟件所有需求，則可以采用這種方式進行增量開發：

1. 不進行整個系統的需求分析和體系結構設計，而是針對每個增量分別進行需求分析、設計、編碼、測試、交付，形成每一次發布。
2. 當所有增量開發完畢並成功集成，則形成系統最終產品。
3. 由於沒有進行整體的需求分析和系統體系結構設計，后面的增量有可能無法集成到前面的發布中，風險較大。

增量的方式

增量的方式可以采取兩種：增量方式或者迭代方式。

增量方式

每個增量是一些新功能，通過增加新功能來增加增量，

迭代方式

每個增量是對一些功能的改進，通過改進功能來增加增量

增量和迭代方式舉例

注：實際使用中，常常是兩種方式的結合。

增量模型的特點

1. 增量模型是一種非整體開發的模型，是一種進化式的開發過程

2. 增量模型從部分需求出發，先建立一個不完整的系統，通過測試運行這個系統取得經驗和反饋，進一步使系統擴充和完善

3. 如此反復進行，直至軟件人員和用戶對所設計的軟件系統滿意為止

4. 增量模型結合了原型模型的基本要素和迭代的特征，采用了基於時間的線性序列，每個線性序列都會輸出該軟件的一個“增量”

5. 每個增量的開發可用瀑布或快速原型模型

優點

1. 增量概念的引入，使得不需要提供完整的需求，只要有一個增量出現，開發就可以進行，軟件能夠更早投入市場。
2. 在項目初期，由於只開發部分系統，不需要投入太多的人力物力。
3. 整個開發過程中，產品逐步交付，軟件開發能夠較好地適應需求的變化，同時能夠看到軟件中間產品，提出改進意見，減少返工，降低開發風險。
4. 增量模型要求系統具有開放式體系結構，以便於增量的集成，同時也便於維護。

缺點

1. 每個增量必須提供一些系統功能，這使得開發者很難根據客戶需求給出大小適合的增量。
2. 其次，軟件必須具備開放式體系結構，這在實踐中往往是困難的。
3. 如果不能進行良好的項目管理，采用增量模型的開發過程很容易退化成邊做邊改的方式，使軟件過程控制失去整體性，從而導致軟件開發失敗。

適用場合

1. 軟件開發中需求可能發生變化、具有較大風險的項目
2. 或者希望盡早進入市場的項目。

螺旋模型

把開發活動和風險管理結合起來控制風險

控制風險

前面課程中講到的原型模型通過原型化降低需求不明確帶來的風險，增量模型通過產品逐步交付降低需求變化帶來的風險，但是當軟件項目具有更大更多風險時，這些方法是不夠的。

在軟件開發過程中加入風險管理。

軟件開發普遍存在風險，例如，最終交付的產品用戶不滿意，產品不能按期交付，開發成本超過了預算，產品開發期間關鍵人員離職，產品投入市場前競爭對手發布了功能相近價格更低的產品，等等。如何應對這些風險對軟件項目的成功開發至關重要。

特點

1. 開發過程分成若干次迭代，每次迭代代表開發的一個階段，對應模型中一條環線
2. 每次迭代分成四個方面的活動，對應笛卡爾坐標的四個象限：
3. 經過若干次迭代后，完成項目開發。

展開：繼承了瀑布模型和原型模型的特點

如果將螺旋模型展開，它實際上是瀑布模型，其中每個階段加入了原型化過程，因此螺旋模型結合了瀑布模型和原型模型的特點。

以圖為例：

1. 第一次迭代，即第一條環線，產生操作概念

2. 第二次迭代，即第二條環線，產生軟件需求

3. 第三次迭代產生軟件設計

4. 第四次迭代產生軟件實現。

   每一次迭代都首先進行預算、方案、約束，然后進行風險分析，並通過原型化進行驗證，降低或消除風險；如果風險可消除，則繼續進行開發驗證，形成本階段成果；最后計划下一階段。

優點

1、螺旋模型強調原型的可擴充性和可修改性，原型的進化貫穿整個軟件生存周期，這將有助於目標軟件的適應能力，支持用戶需求的動態變化；

2、原型可看作可執行的需求規格說明，易於為用戶和開發人員共同理解，還可作為繼續開發的基礎，並為用戶參與所有關鍵決策提供了方便；

3、螺旋模型為項目管理人員及時調整管理決策提供了方便，進而可降低開發風險。

缺點

1. 由於每次迭代都會進行復雜的風險管理，如果每次迭代的效率不高，致使迭代次數過多，將會增加成本並推遲交付時間；
2. 使用該模型需要有相當豐富的風險評估經驗和專門知識，要求開發隊伍水平高，否則會帶來更大風險。

適用場合

1. 螺旋模型適用於需求不明確或者需求可能發生變化的大型復雜的軟件系統，也就是風險較大的復雜系統。
2. 由於其復雜的項目管理，簡單的軟件系統不建議使用螺旋模型。
3. 螺旋模型支持面向過程、面向對象等多種軟件開發方法，是一種具有廣闊前景的模型。

噴泉模型（Fountain model）

噴泉模型是一種以用戶需求為動力，以對象為驅動的模型，主要用於描述面向對象的軟件開發過程
軟件開發早期定義對象，整個開發過程充實和擴充對象
各個階段使用統一的概念和表示方法，生命周期各階段無縫連接
各個開發步驟多次反復迭代

一共五個階段

各個開發階段使用統一的概念和表示方法，因此各階段之間無縫連接。各個開發階段可以多次反復迭代，最終開發出完整的系統。

優點

噴泉模型的各個階段沒有明顯的界限，開發人員可以同步進行開發，可以提高軟件項目開發效率，節省開發時間，適應於面向對象的軟件開發過程。

缺點

1. 由於噴泉模型在各個開發階段是重疊的，在開發過程中需要大量的開發人員，因此項目管理麻煩。
2. 噴泉模型要求嚴格管理文檔，使得審核的難度大，尤其是面對可能隨時加入的各種信息、需求與資料的情況。

適用場合

面向對象開發