瀑布模型 

瀑布模型（經典生命週期）提出了軟體開發的系統化的、順序的方法。其流 程從使用者需求規格說明開始，通過策劃、建模、構建和部署的過程，最終提供一 個完整的軟體並提供持續的技術支援。

優點：

1. 強調開發的階段性，各階段具有順序性和依賴性

2. 強調早期調研和需求分析，推遲編碼實現的觀點

3.  提供了一個摸板，這個摸板使得分析、設計、編碼、測試和支援的方法可以 在該摸板下有一個共同的指導

缺點：

1. 文件驅動，使用者無法及時瞭解產品的情況

2. 依賴早期調研和需求分析，很難適應在許多專案開始階段必然存在的不確定 性。

3.  流程單一，必須要完成前一階段的任務，才能進行下一階段，開發過程中的 成功經驗無法用於本產品。

4.  測試在後期引入，對於系統存在的重大缺陷，如果在可執行程式評審之前沒 有被發現，將可能造成重大損失。

5. 組織龐大，人員閒置。

適用範圍：需求確定，工作能夠採用線性的方式完成的軟體。

增量過程模型

增量過程模型包括增量模型、RAD 模型。

（一）增量模型 增量過程模型以迭代的方式運用瀑布模型，把軟體產品作為一系列的增量構件來設計、編碼、整合和測試。

每個構件由多個相互作用的模組構成，並且能夠完成特定的功能。使用增量模型時，第一個增量往往是核心功能。

優點：

1.能在較短的時間內向使用者提交可完成部分工作的產品。

2.逐步增加產品功能可以使使用者有充裕的時間學習和適應新產品，從而減少一個 全新的軟體可能給客戶組織帶來的衝擊。

3. 規避技術風險

4. 可並行開發構件，加快開發的進度

缺點：

1.  沒有考慮軟體的整體質量和長期的可維護性。

2.  大部分情況是不合適的操作演算法被採用目的為了演示功能，不合適的開發工 具被採用僅僅為了它的方便，還有不合適的作業系統被選擇等等。

3.  由於達不到質量要求產品可能被拋棄，而採用新的模型重新設計

適用範圍：專案在既定的商業要求期限之前不可能找到足夠的開發人員；

 

（二）RAD模型

RAD  模型是一種側重於短暫的開發週期的增量軟體過程模型，它是瀑布模 型的“高速”變體，通過基於構建的構建方法實現快速開發。

開發團隊能夠在非常短的時間內創造出“全功能系統”

優點：

1．開發速度快，質量有保證。

2．對資訊系統特別有效。

缺點：

1.  對於大型的可伸縮的專案，RAD 需要大量的人力資源來建立多個相對的獨立 的 RAD 團隊

2.  如果開發者和使用者沒有為短時間內急速完成整個系統做好準備，RAD 專案將會失敗。

3.  如果一個系統不能合理的模組化，RAD 構件建立會有很多問題。

4.  如果系統需求是高效能，並且需要通過調整構件介面的方式來提高效能，不 能採用 RAD 模型

5.  技術風險很高的情況下

適用範圍：1、 不適合技術風險很高的開發，不適合系統需求是高效能，並且需 要通過調整構件介面的方式來提高效能的產品開發。

2、 適用於工期緊張，又可細分功能，還要有合適的構件

演化過程模型

演化過程模型包括原型開發，螺旋模型，協同開發模型。

（一）原型開發 從需求收集開始，開發者和客戶在一起定義軟體的總體目標，標識已知的需求並且規劃出需要進一步定義的區域。

然後是“快速設計”，它集中於軟體中那些 對客戶可見的部分的表示，這將導致原型的建立，並由客戶評估並進一步精化待 開發軟體的需求。

逐步調整原型使其滿足客戶的需求，這個過程是迭代的。其流 程從聽取客戶意見開始、隨後是建造/修改原型、客戶測試執行原型、然後回頭 往復迴圈直到客戶對原型滿意為止。

由於這種模型可以讓客戶快速的感受到實際 的系統（雖然這個系統不帶有任何質量的保證），所以客戶和開發者都比較喜歡 這種過程模型（對於那些僅僅用來演示軟體功能的公司而言或從來不考慮軟體質

量和不害怕長期維護的公司而言）。

 

優點：

1、能讓人（開發者或客戶）很快見到產品，有成就感。

2、能漸進地啟發客戶提出新的要求或任務。

缺點：

1、 沒有考慮軟體的整體質量和長期的可維護性。

2、 大部分情況是不合適的操作演算法被採用目的為了演示功能，不合適的開發工具被採用僅僅為了它的方便，還有不合適的作業系統被選擇等等。

3、 由於達不到質量要求產品可能被拋棄，而採用新的模型重新設計。

（二）螺旋模型 螺旋模型是一種演進式軟體過程模型，結合了原型的迭代性質和瀑布模型的系統性和可控性的特點，具有快速開發越來越完善軟體版本的潛力。

開發步驟：沿螺線自內向外，每旋轉一圈便開發出更為完善的一個新的軟體版本。

例如，在第一圈，確定了初步的目標、方案和限制條件以後，轉入右上象限，對風險進行識別和分析。

如果風險分析表明，需求有不確定性，那麼在右下 的工程象限內，所建的原型會幫助開發人員和客戶，考慮其它開發模型，並對需求做進一步修正。客戶對工程成果做出評價之後，給出修正建議。

在此基礎上需 再次計劃，並進行風險分析。在每一圈螺線上，風險分析的終點做出是否繼續下 去的判斷。

假如風險過大，開發者和使用者無法承受，專案有可能終止。多數情況 下沿螺線的活動會繼續下去，自內向外，逐步延伸，最終得到所期望的系統。

優點：

1. 強調風險

2. 強調階段質量

3. 提供糾錯的機會

缺點：

1. 每個階段都要提出被選方案，進行風險分析，研發週期長，效率低

2. 必須要轉業的風險分析人員的參與

適用範圍：大型專案

（三）協同開發模型 協同開發模型(協同工程)，可以表示唯一系列的框架活動、軟體工程動作和任務 以及相應的狀態。

適用範圍：所有型別的軟體開發

專用過程模型

包括基於構件的開發、形式化方法模型、面向方面的軟體開發。

(一)基於構件的開發基於構件的開發模型具有許多螺旋模型的特點，本質上是演化模型，需要以 迭代方式構建軟體。不同之處在於，基於構件開發模型採用預先打包的軟體構件 開發程式。

開發過程：對所需構件進行評估 → 考慮構件的整合 → 設計系統的軟體框 架→將構件放入框架→進行測試

優點：

1. 構件可複用。提高了開發效率。

2.  採用了面嚮物件的技術

3.  能夠使軟體複用

缺點：過分依賴於構件，構件庫的質量影響著產品質量。

（二）形式化方法模型 形式化方法模型包含了一組活動，他們導致了計算機軟體的數學規約。

形式化方法使得軟體工程師們能夠通過應用一個嚴格的數學符號體系來規約、開發、 和驗證基於計算機的系統。

這種方法的一個變種，稱為淨室軟體工程，已經被 一些組織所採用。

在開發中使用形式化方法時，它們提供了一種機制，能夠消除 使用其它軟體過程模型難以克服的很多問題。

二義性、不完整性、不一致效能被 更容易地發現和糾正，而不是通過專門的評審，是通過對應用的數學分析。

形式化方法提供了可以產生無缺陷軟體的承諾。

優點：

1、形式化規約可直接作為程式驗證的基礎，可以儘早的發現和糾正錯誤（包括 那些其它情況下不能發現的錯誤）。

2、開發出來的軟體具有很高的安全性和健壯性，特別適合安全部門或者軟體錯 誤會造成經濟損失的開發者。

3、能夠開發出無缺陷軟體。

缺點：

1、 開發費用昂貴，而且需要的時間較長。

2、 需要大量的培訓。

3、 不能將這種模型作為對客戶通訊的機制，因為客戶對這些數學語言一無所 知。

適用範圍：不適用於技術水平不高的客戶。

（三）面向方面的軟體開發 將系統分成若干相對較獨立的組成部分，這些部分稱為方面。

優點：超越了子程式和繼承的方法。 缺點：技術還不成熟

統一過程模型

統一過程模型是一種“用例驅動、以體系結構為核心、迭代及增量”的軟體 過程框架，由 UML 方法和工具支援。它是一種增量模型，定義了五個階段：

a、起始階段，包括使用者溝通和計劃活動，強調定義和細化用例

b、 細化階段，包括使用者溝通和建模活動，重點是建立分析和設計模型。

c、構件階段，細化模型設計，並將設計模型轉化為軟體構件實現

d、 轉化階段，將軟體從開發人員傳遞給終端使用者，並由使用者完成 beta 測試和驗 收測試 

e、生產階段，持續地監控軟體的執行，並提供技術支援。

優點：

1. 任何功能開發後就進入測試過程，及早進行驗證

2. 早期風險識別，採取預防措施

缺點：

1. 需求必須在開始之前完全弄清楚，否怎有可能在架構上出現錯誤

2. 必須有嚴格的過程管理，以免使過程退化為原始的試→錯→改模式

3．如果不加控制的讓使用者過早接觸沒有測試完全，版本不穩定的產品可能對用 戶和開發團隊都帶來負面的影響