軟件生命週期模型 -------- 瀑布模型 和 原型模型

瀑布模型（Waterfall Model）

模型概述：

瀑布模型：是一個軟件生命週期模型，開發過程是通過設計一系列階段順序展開的，從系統需求分析開始直到產品發佈和維護，項目開發進程從一個階段“流動”到下一個階段，這也是瀑布模型名稱的由來。

核心思想：

瀑布模型核心思想是：按工序將問題化簡，將功能的實現與設計分開，便於分工協作，即採用結構化的分析與設計方法將邏輯實現與物理實現分開。
將軟件生命週期劃分爲制定計劃、需求分析、軟件設計、程序編寫、軟件測試和運行維護等六個基本活動，並且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。

模型特點：

1. 從上一項開發活動接受其成果作爲本次活動的輸入。
2. 用這一輸入，實施本次活動應完成的工作內容。
3. 給出本次活動的工作成果，作爲輸出傳給下一項開發活動。
4. 對本次活動的實施工作成果進行評審。若其工作成果得到確認，則繼續進行下一項開發活動；否則返回前一項，甚至更前項的活動。儘量減少多個階段間的反覆。以相對來說較小的費用來開發軟件。

優點：

1. 開發的各個階段比較清晰。
2. 強調早期計劃及需求調查。
3. 適合需求穩定的產品開發。

缺點：

1. 依賴於早期的需求調查，不適應需求的變化。
2. 風險往往延至後期才顯露，失去及早糾正的機會。
3. 問題在項目後期纔開始暴露。
4. 前面未發現的錯誤會傳遞並擴散到後面的階段，可能導致項目失敗

分類：

1.傳統瀑布模型：

特點：

(1) 階段間具有順序性和依賴性

必須等前一階段的工作完成之後，才能開始後一階段的工作。前一階段的輸出文檔就是後一階段的輸入文檔。

(2) 推遲實現的觀點

清楚的區分邏輯設計與物理設計，儘可能推程序的物理實現，是因爲編碼之前階段的工作沒做或做得不紮實，過早地考慮進行程序實現，往往導致大量返工，有時甚至發生無法彌補的問題，帶來災難性的後果。實踐也表明，對於規模較大的軟件項目來說，往往編碼開始得越早最終完成開發工作所需要的時間反而越長。

(3) 質量保證的觀點

每個階段都必須完成規定的文檔，沒有交出合格的文檔就是沒有完成該階段的任務。每個階段結束前都要對所完成的文檔進行評審，以便儘早發現問題，改正錯誤。

2.加入迭代的瀑布模型：

原因：
傳統的瀑布模型過於理想化，人在工作過程中不可能不犯錯誤。
特點：
當後面階段發現前面階段的錯誤時，需要沿圖中左側的反饋線返回前面的階段，修正前面階段的產品之後再回來繼續完成後面階段的任務。

原型模型：

實現一個基本原型，讓用戶對原型進行評價，逐步調整，使其滿足用戶最終需求。

優點：

適合不能確定需求的軟件；

缺點：

不適合開發大型系統。