軟體生命周期模型 -------- 瀑布模型 和 原型模型

文章目錄

• • 瀑布模型（Waterfall Model）
  • • 模型概述：
    • 核心思想：
    • 模型特點：
    • 優點：
    • 缺點：
  • 分類：
  • • 1.傳統瀑布模型：
    • 2.加入疊代的瀑布模型：
  • 原型模型：
  • • 優點：
    • 缺點：

瀑布模型（Waterfall Model）

模型概述：

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

核心思想：

瀑布模型核心思想是：按工序将問題化簡，将功能的實作與設計分開，便于分工協作，即采用結構化的分析與設計方法将邏輯實作與實體實作分開。

将軟體生命周期劃分為制定計劃、需求分析、軟體設計、程式編寫、軟體測試和運作維護等六個基本活動，并且規定了它們自上而下、互相銜接的固定次序，如同瀑布流水，逐級下落。

模型特點：

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

優點：

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

缺點：

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

分類：

1.傳統瀑布模型：

特點：

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

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

(2) 推遲實作的觀點

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

(3) 品質保證的觀點

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

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

原因：

傳統的瀑布模型過于理想化，人在工作過程中不可能不犯錯誤。

特點：

當後面階段發現前面階段的錯誤時，需要沿圖中左側的回報線傳回前面的階段，修正前面階段的産品之後再回來繼續完成後面階段的任務。

原型模型：

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

優點：

适合不能确定需求的軟體；

缺點：

不适合開發大型系統。