瀑布模型?

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

優點：

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．如果不加控制的讓用戶過早接觸沒有測試完全，版本不穩定的產品可能對用 戶和開發團隊都帶來負面的影響

總結

以上是生活随笔為你收集整理的几种常见软件过程模型的比较的全部內容，希望文章能夠幫你解決所遇到的問題。

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