軟件開發的四個模型的優缺點

 

一、瀑布模型

優點

1）為項目提供了按階段划分的檢查點。

2）當前一階段完成后，您只需要去關注后續階段。

3）可在迭代模型中應用瀑布模型。

 

瀑布模型有以下缺點：

1）在項目各個階段之間極少有反饋。

2）只有在項目生命周期的后期才能看到結果。

3）通過過多的強制完成日期和里程碑來跟蹤各個項目階段。

 

二、快速原型模型

快速原型模型需要迅速建造一個可以運行的軟件原型 ，以便理解和澄清問題，使開發人員與用戶達成共識，最終在確定的客戶需求基礎上開發客戶滿意的軟件產品。

快速原型模型允許在需求分析階段對軟件的需求進行初步而非完全的分析和定義，快速設計開發出軟件系統的原型，該原型向用戶展示待開發軟件的全部或部分功能和性能；用戶對該原型進行測試評定，給出具體改進意見以豐富細化軟件需求；開發人員據此對軟件進行修改完善，直至用戶滿意認可之后，進行軟件的完整實現及測試、維護。

快速原型是利用原型輔助軟件開發的一種新思想。經過簡單快速分析，快速實現一個原型，用戶與開發者在試用原型過程中加強通信與反饋，通過反復評價和改進原型，減少誤解，彌補漏洞，適應變化，最終提高軟件質量。

優點

1） 克服瀑布模型的缺點，減少由於軟件需求不明確帶來的開發風險。

缺點

1） 所選用的開發技術和工具不一定符合主流的發展；

2）快速建立起來的系統結構加上連續的修改可能會導致產品質量低下；

 

2.1模型類型

探索型原型

這種類型的原型是把原型用於開發的需求分析階段，目的是要弄清用戶的需求，確定所期望的特性，並探索各種方案的可行性。它主要針對開發目標模糊，用戶與開發都對項目都缺乏經驗的情況，通過對原型的開發來明確用戶的需求。

實驗型原型

這種原型主要用於設計階段，考核實現方案是否合適，能否實現。對於一個大型系統，若對設計方案心中沒有把握時，可通過這種原型來證實設計方案的正確性。

演化型原型

這種原型主要用於及早向用戶提交一個原型系統，該原型系統或者包含系統的框架，或者包含系統的主要功能，在得到用戶的認可后，將原型系統不斷擴充演變為最終的軟件系統。它將原型的思想擴展到軟件開發的全過程。

 

2.2 開發步驟

快速分析

在分析人員與用戶密切配合下，迅速確定系統的基本需求，根據原型所要體現的特征描述基本需求以滿足開發原型的需要。

構造原型

在快速分析的基礎上，根據基本需求說明盡快實現一個可行的系統。這里要求具有強有力的軟件工具的支持，並忽略最終系統在某些細節上的要求，如安全性、堅固性、例外處理等等，主要考慮原型系統能夠充分反映所要評價的特性，而暫時刪除一切次要內容。

運行原型

這是發現問題、消除誤解、開發者與用戶充分協調的一個步驟。

評價原型

在運行的基礎上，考核評價原型的特性，分析運行效果是否滿足用戶的願望，糾正過去交互中的誤解與分析中的錯誤，增添新的要求，並滿足因環境變化或用戶的新想法引起的系統要求變動，提出全面的修改意見。

修改

根據評價原型的活動結果進行修改。若原型未滿足需求說明的要求，說明對需求說明存在不一致的理解或實現方案不夠合理，則根據明確的要求迅速修改原型。

 

三、螺旋模型

 

優點

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

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

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

4）隨着項目推進,客戶始終掌握項目的最新信息 , 從而他或她能夠和管理層有效地交互。

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

 

缺點

很難讓用戶確信這種演化方法的結果是可以控制的。

建設周期長，而軟件技術發展比較快，所以經常出現軟件開發完畢后，和當前的技術水平有了較大的差距，無法滿足當前用戶需求。

 

四、增量模型

增量模型是把待開發的軟件系統模塊化，將每個模塊作為一個增量組件，從而分批次地分析、設計、編碼和測試這些增量組件。運用增量模型的軟件開發過程是遞增式的過程。相對於瀑布模型而言，采用增量模型進行開發，開發人員不需要一次性地把整個軟件產品提交給用戶，而是可以分批次進行提交。

增量模型又稱為漸增模型，也稱為有計划的產品改進模型，它從一組給定的需求開始，通過構造一系列可執行中間版本來實施開發活動。第一個版本納入一部分需求，下一個版本納入更多的需求，依此類推，直到系統完成。每個中間版本都要執行必需的過程、活動和任務。

增量模型是瀑布模型和原型進化模型的綜合，它對軟件過程的考慮是：在整體上按照瀑布模型的流程實施項目開發，以方便對項目的管理；但在軟件的實際創建中，則將軟件系統按功能分解為許多增量構件，並以構件為單位逐個地創建與交付，直到全部增量構件創建完畢，並都被集成到系統之中交付用戶使用。

如同原型進化模型一樣，增量模型逐步地向用戶交付軟件產品，但不同於原型進化模型的是，增量模型在開發過程中所交付的不是完整的新版軟件，而只是新增加的構件。 上圖是增量模型的工作流程，它被分成以下三個階段：

1、在系統開發的前期階段，為了確保所建系統具有優良的結構，仍需要針對整個系統進行需求分析和概要設計，需要確定系統的基於增量構件的需求框架，並以需求框架中構件的組成及關系為依據，完成對軟件系統的體系結構設計。

2、在完成軟件體系結構設計之后，可以進行增量構件的開發。這個時候，需要對構件進行需求細化，然后進行設計、編碼測試和有效性驗證。

3、在完成了對某個增量構件的開發之后，需要將該構件集成到系統中去，並對已經發生了改變的系統重新進行有效性驗證，然后再繼續下一個增量構件的開發。

 

優點

•整個項目的資金不會被提前消耗，因為首先開發和交付了主要功能和高風險功能。 •每個增量交付一個可操作的產品。

•每次增量交付過程中獲取的經驗，有利於后面的改進，客戶也有機會對建立好的模型作出反應。

•采用連續增量的方式，可把用戶經驗融入到細化的產品，這比完全重新開發要便宜得多。

•“分而治之”的策略，使問題分解成可管理的小部分，避免開發團隊由於長時間的需求任務而感到淚喪。

•通過同一個團隊的工作來交付每個增量，保持所有團隊處於工作狀態，減少了員工的工作量，工作分布曲線通過項目中的時間階段被拉平。

•每次增量交付的結為，可以重新修訂成本和進度的風險。

•便於根據市場作出反應。

•降低了失敗和更改需求的風險。

•更易於控制用戶需求，因為每次曾兩開發的時間很短。

•由於不是一步跳到未來，所以用戶能逐步適應新技術。

•切實的項目進展，有利於進度控制。

•風險分布到幾個更小的增量中，而不是集中於一個大型開發中。

•由於用戶能夠從早期的增量中了解系統，所以更加理解后面增量中的需求。 增量模型有以下缺點

•若軟件可拆卸度不高，開發人員全局把握水平不高，用戶不同意分階段提交產品，或者開發人員過剩，都不適宜。

 

 

 

參考

增量模型，百度百科，2019.3.

迭代模型，百度百科，2019.3.

4種模型的優缺點，百度用戶19930604.