軟件過程模型

軟件生命周期

• 從設計、投入使用到被淘汰的全過程
• 注意這里不只是設計、連維護也是
• 每個過程會產生相應的文檔

軟件過程模型

• 也稱為軟件開發模型、軟件生存周期模型
• 結構框架
• 能直觀表達軟件開發全過程

能力成熟度模型

• 用來評估軟件的生產能力
• CMM是目前國際上使用流行的一種軟件生產過程行業標準模型，可定義、評價軟件開發過程的成熟度，并提供提高軟件質量的指導。
• CMM模型分為五級：初始級(1級)、可重復級(2級)、定義級(3級)、管理級(4級)、優化級(5級)共5個成熟度等級，低級別是實現高級別的基礎

對應說明：
(1)初始級(initial)。

• 工作無序，項目進行過程中常放棄當初的計劃。
  管理無章法，缺乏健全的管理制度。開發項目成效不穩定，項目成功主要依靠項目負責人的經驗和能力，他一但離去，工作秩序面目全非。

(2)可重復級(Repeatable)。

• 管理制度化，建立了基本的管理制度和規程，管理工作有章可循。
  初步實現標準化，開發工作比較好地按標準實施。
  變更依法進行，做到基線化，穩定可跟蹤，新項目計劃和管理基于過去實踐經驗，具有重復以前成功項目的環境和條件。
  核心：建立基本的項目管理和實踐來跟蹤項目費用、進度和功能特性

(3)已定義級(Defined)。

• 許多組織追求的目標
  開發過程，包括技術工作和管理工作，均已實現標準化、文檔化。
  建立了完善的培訓制度和專家評審制度，全部技術活動和管理活動均可控制，對項目進行中的過程、崗位和職責均有共同的理解 。
  核心：使用標準開發過程(或方法論)構建(或集成)系統

(4)已管理級(Managed)。

• 產品和過程已建立了定量的質量目標。
  開發活動中的生產率和質量是可量度的。
  已建立過程數據庫。
  已實現項目產品和過程的控制。
  可預測過程和產品質量趨勢，如預測偏差，實現及時糾正。
  核心：管理層尋求更主動地應對系統的開發問題

(5)優化級(Optimizing)。

• 可集中精力改進過程，采用新技術、新方法。
  擁有防止出現缺陷、識別薄弱環節以及加以改進的手段。
  可取得過程有效性的統計數據，并可據進行分析，從而得出最佳方法。
  核心：連續地監督和改進標準化的系統開發過程

傳統的軟件過程模型

瀑布模型

• 瀑布模型（Waterfall Model） 是一個軟件生命周期模型，開發過程是通過設計一系列階段順序展開的，從系統需求分析開始直到產品發布和維護，項目開發進程從一個階段“流動”到下一個階段，這也是瀑布模型名稱的由來。
• 是一種使用廣泛，以文檔為驅動的模型
• 每個階段都有與其相關聯的里程碑和可交付產品
• 每個階段結束前完成文檔審查，及早改正錯誤

特點

• 階段間具有順序性和依賴性
  必須等前一階段的工作完成之后，才能開始后一階段的工作。前一階段的輸出文檔就是后一階段的輸入文檔。
• 推遲實現的觀點
  清楚的區分邏輯設計與物理設計，盡可能推程序的物理實現，是因為編碼之前階段的工作沒做或做得不扎實，過早地考慮進行程序實現，往往導致大量返工，有時甚至發生無法彌補的問題，帶來災難性的后果。
• 質量保證的觀點
  每個階段都必須完成規定的文檔，沒有交出合格的文檔就是沒有完成該階段的任務。
  每個階段結束前都要對所完成的文檔進行評審，以便盡早發現問題，改正錯誤。

實際模型

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

缺點

• 瀑布模型是由文檔驅動，在可運行的軟件產品交付給用戶之前，用戶只能通過文檔來了解產品是什么樣的。瀑布模型幾乎完全依賴于書面的規格說明，很可能導致最終開發出的軟件產品不能真正滿足用戶的需要。也不適合需求模糊的系統。
• 測試只是其中一個階段，缺乏全過程測試思想

應用場合

• 適用于系統需求明確且穩定、技術成熟、工程管理較嚴格的場合，如軍工、航天、醫療

V模型

• V模型的中心思想是，研發人員和測試人員需要同時工作，在軟件做需求分析的同時就會有測試用例的跟蹤，這樣可以盡快找出程序錯誤和需求偏離，從而更高效的提高程序質量，最大可能的減少成本，同時滿足用戶的實際軟件需求。
• V模型的重要意義在于，非常明確的表明了測試過程中存在的不同的級別，并且非常清晰的描述了這些測試階段和開發階段的對應關系。
  單元測試：是否滿足詳細設計的要求
  集成測試：驗證已測試過的部分是否可以很好地結合在一起
  系統測試：檢驗系統功能、性能是否達到系統的要求。
  驗收測試：確定軟件的時限是否滿足用戶需求或合同需求

特點

• V模型體現的主要思想是開發和測試同等重要，左側代表的是開發活動，而右側代表的是測試活動。
• V模型針對每個開發階段，都有一個測試級別與之相對應。
• 測試依舊是開發生命周期中的階段，與瀑布模型不同的是，有多個測試級別與開發階段對應。
• V模型適用于需求明確和需求變更不頻繁的情形。

缺點

• 雖然測試盡早的進入到開發階段，但是真正進行軟件測試是在編碼之后，這樣忽視了測試對需求分析，系統設計的驗證，時間效率上也大打折扣。

原型模型

博客出處

• 在開發真實系統之前，通過構建一個可以運行的軟件原型，使開發人員與用戶達成共識，以便理解和澄清問題，最終在確定的客戶需求基礎上開發客戶滿意的軟件產品。

• 根據運用原型的目的和方式不同，可以將原型模型分為快速原型模型（拋棄型）和原型進化模型（漸進型）。
  
  

快速原型模型

• 快速原型模型是原型模型在軟件分析、設計階段的應用，用來解決用戶對軟件系統在需求上的模糊認識，或用來試探某種設計是否能夠獲得預期結果。

特點

• 快速原型是用來獲取用戶需求的，或是用來試探設計是否有效的。一旦需求或設計確定下來了，原型就將被拋棄。因此，快速原型要求快速構建、容易修改，以節約原型創建成本、加快開發速度。快速原型往往采用一些快速生成工具創建，例如 4GL 語言。目前，Microsoft Visual Basic、Inprise Delphi 等基于組件的可視化開發工具，也被應用于原型創建之中，并且都是非常有效的快速原型創建工具，而且還可用于原型進化。

• 快速原型是暫時使用的，因此并不要求完整。它往往針對某個局部問題建立專門原型， 如界面原型、工作流原型、查詢原型等。

• 快速原型不能貫穿軟件的整個生命周期，它需要和其他的過程模型相結合才能產生作 用。例如，在瀑布模型中應用快速原型，以解決瀑布模型在需求分析時期存在的不足。

原型進化模型（演化模型）

• 原型進化對開發過程的考慮是，針對有待開發的軟件系統，先開發一個原型系統給用戶使用，然后根據用戶使用情況的意見反饋，對原型系統不斷修改，使它逐步接近并最終到達開發目標。跟快速原型不同的是，快速原型在完成需求定義后將被拋棄，而原型進化所要創建的原型則是一個今后將要投入應用的系統，只是所創建的原型系統在功能、性能等方面還有許多不足，還沒有達到最終開發目標，需要不斷改進。 原型進化的工作流程如圖所示。

特點

• 原型進化模型將原型用于開發的全過程，原型由最基本的核心開始，逐步增加新的功能和新的需求，反復修改反復擴充，最后發展為用戶滿意的最終系統。
• 原型進化模型是通過不斷發布新的軟件版本而使軟件逐步完善的，因此，這種開發模式特別適合于那些用戶急需的軟件產品開發。它能夠快速地向用戶交付可以投入實際運行的軟件成果，并能夠很好地適應軟件用戶對需求規格的變更。原型進化模型能夠適應軟件需求的中途變更

問題

• 原型進化模型雖說使開發進程加快了，但不能像瀑布模型那樣提供明確的里程碑管理，隨著開發過程中版本的快速更新，項目管理、軟件配置管理會變得復雜起來，管理者難以把握開發進度。因此，對于大型軟件項目，原型進化模型缺乏有效的管理規程。

• 開發過程中軟件版本的快速變更，還可能損傷軟件的內部結構，使其缺乏整體性和穩定性。另外，用于反映軟件版本變更的文檔也有可能跟不上軟件的變更速度。這些問題必將影響到今后軟件的維護

增量模型

原博文

• 把待開發的軟件系統模塊化，將每個模塊作為一個增量組件，從而分批次地分析、設計、編碼和測試這些增量組件。
  
• 增量模型對軟件過程的考慮是：在整體上按照瀑布模型的流程實施項目開發，以方便對項目的管理；但在軟件的實際創建中，則將軟件系統按功能分解為許多增量構件，并以構件為單位逐個地創建與交付，直到全部增量構件創建完畢，并都被集成到系統之中交付用戶使用。如同原型進化模型一樣，增量模型逐步地向用戶交付軟件產品，但不同于原型進化模型的是，增量模型在開發過程中所交付的不是完整的新版軟件，而只是新增加的構件。

增量模型的優點

• 增量模型的最大特點就是將待開發的軟件系統模塊化和組件化?；谶@個特點，增量模型具有以下優點。
  1、將待開發的軟件系統模塊化，可以分批次地提交軟件產品，使用戶可以及時了解軟件項目的進展。
  2、以組件為單位進行開發降低了軟件開發的風險。一個開發周期內的錯誤不會影響到整個軟件系統。
  3、開發順序靈活。開發人員可以對組件的實現順序進行優先級排序，先完成需求穩定的核心組件。當組件的優先級發生變化時，還能及時地對實現順序進行調整。

增量模型的缺點：

• 1、要求待開發的軟件系統可以被模塊化。如果待開發的軟件系統很難被模塊化，那么將會給增量開發帶來很多麻煩。
  2、由于各個構件是逐漸并入已有的軟件體系結構中的，所以加入構件必須不破壞已構造好的系統部分，這需要軟件具備開放式的體系結構。 　
  3、在開發過程中，需求的變化是不可避免的。增量模型的靈活性可以使其適應這種變化的能力大大優于瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而使軟件過程的控制失去整體性。

增量模型適用范圍：

• 1、軟件產品可以分批次地進行交付。
  2、待開發的軟件系統能夠被模塊化。
  3、軟件開發人員對應用領域不熟悉，難以一次性地進行系統開發。
  4、項目管理人員把握全局的水平較高。

螺旋模型

• 螺旋模型是快速原型法以進化的開發方式為中心，在每個項目階段使用瀑布模型法。這種模型的每一個周期都包括需求定義、風險分析、工程實現和評審4個階段，由這4個階段進行迭代。螺旋模型即是一種引入了風險分析與規避機制的過程模型，是瀑布模型、快速原型方法和風險分析方法的有機結合。螺旋模型最大的特點在于引入了其他模型不具備的風險分析，使軟件在無法排除重大風險時有機會停止，以減小損失。

優點

• 設計上的靈活性,可以在項目的各個階段進行變更。

• 以小的分段來構建大型系統,使成本計算變得簡單容易。

• 客戶參與每個階段的開發,保證了項目不偏離正確方向及項目的可控性。

• 客戶始終掌握項目的最新信息, 能夠和管理層有效地交互。

• 客戶認可這種公司內部的開發方式帶來的良好的溝通和高質量的產品。

噴泉模型

• 噴泉模型是一種以用戶需求為動力，以對象為驅動的模型，主要用于描述面向對象的軟件開發過程。該模型認為軟件開發過程自下而上周期的各階段是相互重疊和多次反復的，就像水噴上去又可以落下來，類似一個噴泉。各個開發階段沒有特定的次序要求，并且可以交互進行，可以在某個開發階段中隨時補充其他任何開發階段中的遺漏。

總結

以上是生活随笔為你收集整理的瀑布模型、V模型、原型模型、增量模型、螺旋模型、喷泉模型的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。