分類:html
瀑布模型、 增量模型、演化模型(原型模型、螺旋模型)、噴泉模型、基於構件的開發模型、形式化方法模型架構
容易理解,管理成本低;強調開發的階段性早期計劃及需求調查和產品測試。工具
不足之處是,客戶必須可以完整、正確和清晰地表達他們的須要;在開始的兩個或3個階段中,很難評估真正的進度狀態;當接近項目結束時,出現了大量的集成和測試工做:直到項目結束以前,都不能演示系統的能力。開發工具
在瀑布模型中,需求或設計中的錯誤每每只有到了項目後期纔可以被發現,對於項目風險的控制能力較弱,從而致使項目經常延期完成,開發費用超出預算。測試
(1)開發過程通常不能逆轉,不然代價太大;編碼
(2)實際的項目開發很難嚴格按該模型進行;spa
(3)客戶每每很難清楚地給出全部的需求,而該模型卻要求如此。設計
(4)軟件的實際狀況必須到項目開發的後期客戶才能看到,這要求客戶有足夠的耐心。htm
(1)用戶的需求很是清楚全面,且在開發過程當中沒有或不多變化;對象
(2)開發人員對軟件的應用領域很熟悉;
(3)用戶的使用環境很是穩定;
(4)開發工做對用戶參與的要求很低。
它是以文檔做爲驅動、適合於軟件需求分明的軟件項目的模型
做爲瀑布模型的一個變體,具備瀑布模型的全部優勢。此外,它還有如下優勢:
(1)第一個可交付版本所須要的成本和時間不多;
(2)開發由增量表示的小系統所承擔的風險不大;
(3)因爲很快發佈了第一個版本,所以能夠減小用戶需求的變動;
(4)運行增量投資,即在項目開始時,能夠僅對一個或兩個增量投資。
(1)並行開發構件有可能遇到不能集成的風險,軟件必須具有開放式的體系結構;
(2)增量模型的靈活性可使其適應這種變化的能力大大優於瀑布模型和快速原型模型,但也很容易退化爲邊作邊改模型,從而是軟件過程的控制失去總體性。
(1)進行已有產品升級或新版本開發,增量模型是很是適合的;
(2)對完成期限嚴格要求的產品,可使用增量模型;
(3)對所開發的領域比較熟悉並且已有原型系統,增量模型也是很是適合的。
增量模型適用於需求比較明確,架構比較穩定的軟件開發,每次增量不影響已有的架構,在已有的架構下增長新的功能。迭代模型適用於需求不甚明確、難度比較大的軟件開發。
(1)能夠獲得比較良好的需求定義,容易適應需求的變化;
(2)有利於開發與培訓的同步;
(3)開發費用低、開發週期短且對用戶更友好。
(1)客戶與開發者對原型理解不一樣;
(2) 準確的原型設計比較困難;
(3) 不利於開發人員的創新。
(1)對所開發的領域比較熟悉並且有快速的原型開發工具;
(2)項目招投標時,能夠以原型模型做爲軟件的開發模型;
(3)進行產品移植或升級時,或對已有產品原型進行客戶化工做時,原型模型是很是適合的。
適用於用戶需求不清、需求常常變換的狀況。當系統規模不是很大也不是太複雜時,採用該方法比較好
(1)設計上的靈活性,能夠在項目的各個階段進行變動;
(2)以小的分段來構建大型系統,使成本計算變得簡單容易;
(3)客戶始終參與每一個階段的開發,保證了項目不偏離正確方向以及項目的可控性;
(4) 隨着項目推動,客戶始終掌握項目的最新信息 , 從而他或她可以和管理層有效地交互。
(1)採用螺旋模型須要具備至關豐富的風險評估經驗和專門知識,在風險較大的項目開發中,若是未可以及時標識風險,勢必形成重大損失;
(2)過多的迭代次數會增長開發成本,延遲提交時間。
螺旋模型只適合於大規模的軟件項目。
對於新近開發,需求不明確的狀況下,適合用螺旋模型進行開發,便於風險控制和需求變動。
噴泉模型是-種以用戶需求爲動力,以對象做爲驅動的模型,適合於面向對象的開發方法。
它克服了瀑布模型不支持軟件重用和多項開發活動集成的侷限性。
噴泉模型使開發過程具備迭代性和無間隙性,迭代意味着模型中的開發活動經常須要重複屢次,在迭代過程當中不斷地完善軟件系統。無間隙是指在開發活動(如分析、設計、編碼)之大間不存在明顯的邊界,也就 是說,它不像瀑布模型那樣,在需求分析活動結束後纔開始設計活動,在設計活動結束後纔開始編碼活動,而是容許各開發活動交叉、迭代地進行。
噴泉模型主要用於面向對象的軟件項目,軟件的某個部分一般被重複屢次,相關對象在每次迭代中隨之加入漸進的軟件成分。
基於構件的開發模型具備許多螺旋模型的特色,它本質上是演化模型,須要以迭代方式構建軟件。
其不一樣之處在於,基於構建的開發模型採用預先打包的軟件構建開發應用系統
生成計算機軟件形式的數學規格說明
參考具體:http://www.javashuo.com/article/p-devlzyuj-gb.html 【5、敏捷方法】
(已經補充完整)