總結基本的軟體開發模式

2021-08-26 22:08:15 字數 2548 閱讀 8625

快速原型模型

需要迅速造乙個可以執行的軟體原型,以便理解和澄清問題

快速原型模型允許在需求分析階段對軟體的需求進行初步的非完全的分析和定義,快速設計開發出軟體系統的原型(展示待開發軟體的全部或部分功能和效能(過程:使用者對該原型進行測試評定,給出具體改善的意見以及豐富的細化軟體需求,開發人員進行修改完善)

優點:克服瀑布模型的缺點,減少由於軟體需求不明確帶來的開發風險

缺點:a、 所選用的開發技術和工具不一定符合主流的發展

b、 快速建立起來的系統加上連續的修改可能會造成 產品質量底下

增量模型

採用隨著日程時間的進展而交錯的線性序列,每乙個線性徐磊產生軟體的乙個可發布的「增量」,第乙個增量往往就是核心的產品,與其他模型共同之處:它與原型實現模型和其他演化方法一樣,本質都是迭代與原型實現模型不同之處:它強調每乙個增量均發布乙個可操作產品,它不需要等到所有需求都出來,只要摸個需求的增量包出來即可進行開發

優點:1、 人員分配靈活,一開始不需要投入大量人力資源

2、 當配備人員不能在限定的時間內完成產品時,它可以提供一種先推出核心產品的途徑,可現發布部分功能給使用者(對使用者起鎮靜作用)

3、 增量能夠有計畫的管理技術風險

缺點:1、 如果增量包之間存在相交的情況且未很好處理,則必須做全盤系統分析

注:這種模型將功能細化後分別開發的方法較適應於需求經常改變的軟體開發過程

原型模型

樣品模型,採用逐步求精的方法完善原型

主要思想:先借用已有系統作為原型模型,通過「樣品」不斷改進,使得最後的產品就是使用者所需要的。原型模型通過向使用者提供原型獲取使用者的反饋,使開發出的軟體能夠真正反映使用者的需求。

採用方法:原型模型採用逐步求精的方法完善原型,使得原型能夠「快速」開發,避免了像瀑布模型一樣在冗長的開發過程中難以對使用者的反饋作出快速的響應

優點:1、開發人員和使用者在「原型」上達成一致。這樣一來,可以減少設計中的錯誤和開發中的風險,也減少了對使用者培訓的時間,而提高了系統的實用、正確性以及使用者的滿意程度。

2、縮短了開發周期,加快了工程進度。

3、降低成本。  

缺點:1、當重新生產該產品時,難以讓使用者接收,給工程繼續開展帶來不利因素。 

2、不宜利用原型系統作為最終產品。採用原型模型開發系統,使用者和開發者必須達成一致

噴泉模型

以使用者需求為動力,以物件為驅動的模型,主要用於採用物件技術的軟體開發專案

它認為軟體開發過程自下而上週期的各階段是相互迭代和無間隙的特性

相互迭代:軟體的摸個部分常常被重複工作多次,相關物件在每次迭代中隨之加入漸進的軟體成分無間隙:它在各項活動之間沒有明顯邊界(如分析和設計活動之間《由於物件概念的應用,表達分析,設計,實現等活動只用物件類和關係》)

優點:1、 可以提高軟體專案開發效率,節省開發時間,適應於物件導向的軟體開發過程

缺點:1、由於噴泉模型在各個開發階段是重疊的,因此在開發過程中需要大量的開發人員,因此不利於專案的管理。

2、這種模型要求嚴格管理文件,使得審核的難度加大,尤其是面對可能隨時加入各種資訊、需求與資料的情況

螺旋模型

適合用於需求經常變化的專案《適合於大型複雜的系統》

它主要是風險分析與評估,沿著螺線進行若干次迭代

過程:1、 制定計畫:確定軟體目標,選定實施方案,弄清專案開發的限制條件

2、 風險分析:分析評估所選方案,考慮如何識別和消除風險

3、 實施工程:實施軟體開發和驗證;

優點:1、 它由風險驅動,強調可選方案和約束條件從而支援軟體的重用,有助於將軟體質量作為特殊目標融入產品開發中

缺點:1、 難以讓使用者確信這種烟花方法的結果是可以控制的

2、 建設週期長(而軟體技術發展比較快,所以經常會出現軟體開發完畢後,和當前的技術水平有很大的差距,無法滿足當前使用者的需求)

3、 除非軟體開發人員擅長尋找可能的風險,準確的分析風險,否則將會帶來更大的風險

瀑布模型

從本質來講,瀑布模型是乙個軟體開發架構,重複應用

核心思想:按工序將問題化簡,將功能的實現與設計分開,便於分工協作,採用結構化的分析與設計方法將邏輯實現與物理實現分開,依照軟體生命週期自上而下,相互銜接的次序《如同瀑布流水逐級下落》)

缺點:1、 在專案各個階段之間極少有反饋,各個階段的劃分完全固定,階段之間產生大量的文件,增加了工作量

2、 使用者只有在專案生命週期的後期才能看到結果,增加了開發的風險

3、 需要過多的強制完成日期和里程碑來跟蹤各個專案的階段

5、 早期的錯誤可能要等到開發後期的測試階段才能發現,進而帶來嚴重的後果

優點:1、 為專案提供了按階段分的檢查點

2、 當完成乙個階段後,只需要去關注後續階段

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

按照瀑布模型的階段劃分,軟體測試可以分為單元測試,整合測試,系統測試

注:由於每個階段都會產生迴圈反饋,對於經常變化的專案而言,瀑布模型毫無價值,這種模型的線性過程太理想化,已不適合現代的軟體開發模式

軟體開發總結 開發模式選擇

改善協作 想象乙個軟體開發組織,它和市場緊密連線,可以隨時交付完成的工作或調整方向,對市場做出準確的反應,這樣的組織必然會在市場競爭中佔據優勢。響應能力是所有軟體開發組織所期望具備的,但真正能做到的卻很少。究竟是什麼影響了組織的響應能力。從內部看,主要是堆積的 在製品 和技術及學習 債務 從外部看主...

軟體開發模式

軟體的開發模式包括 大棒開發法 邊寫邊改法 瀑布法 快速原型法和螺旋模式法,它們的定義及特點如下 第一,大棒開發法。它是源於能量爆發創造宇宙,萬物都由能量和物質積聚而成的理論,但如果不是遵循某種正確的排列和組合,形成的將不是預先期望的事物 大棒模式與上述理論一樣 一大堆能量 這裡指開發軟體所需的人力...

軟體開發模式

軟體開發模式大概有11種,如下所示 邊做邊改模型 build and fix model 瀑布模型 wate ll model 快速原型模型 rapid prototype model 增量模型 incremental model 迭代模型 stagewise model 螺旋模型 spiral m...