l 各個階段劃分徹底固定,階段之間產生大量文檔,極大增長工做量。測試
l 用戶只有等到整個線性過程的末期才能見到開發成果,從而增長開發風險。編碼
l 早期的錯誤可能要等到開發後期的測試階段才能發現,進而帶來嚴重後果。設計
l 各個構件逐步併入已有軟件體系結構中,所加入構件必須不破壞已構造好的系統部分,須要軟件具有開放式的體系結構。生命週期
l 軟件開發過程當中,需求變化不可避免,該模型容易退化成邊作邊改,對整個軟件過程失去總體控制性。開發
l 設計靈活,能夠在項目各個階段進行變動。文檔
l 以小分段構建大型系統,使成本計算簡單容易。原型
l 客戶始終參與每一個階段,保證項目不偏離方向。產品
l 建設週期長,軟件技術發展比較快,常常出現軟件開發完畢後,與當前技術水平差距大,沒法知足當前需求。基礎
l 螺旋模型事先定義大部分需求,開發過程當中計劃性強;增量模型事先定義少部分需求。軟件
l 螺旋模型在開發週期內採用簡化瀑布模型或快速模型,而增量模型是先作整體需求分析和設計,再在編碼和測試中逐個增量開發。
l 螺旋模型每次迭代都提交一個完整軟件版本,而增量開發每次在上次增量基礎上提交新的一部分軟件。
l 增量模型經過避免使用未成熟技術和常常的用戶反饋等方法減小風險;螺旋模型中直接增長了風險分析,評價所選方案,識別和消除風險。
l 在前期需求明確的狀況下儘可能採用瀑布模型或改進型的瀑布模型。
l 在用戶無信息系統使用經驗,需求分析人員技能不足狀況下必定要藉助原型。
l 在不肯定性因素不少,不少東西前面沒法計劃狀況下儘可能採用增量迭代和螺旋模型。
l 在需求不穩定狀況下儘可能採用增量迭代模型。
l 在資金和成本沒法一次到位狀況下能夠採用增量模型,軟件產品分多個版本進行發佈。
l 對於徹底多個獨立功能開發能夠在需求階段就分功能並行,但每一個功能內都應該遵循瀑布模型。
l 對於全新系統的開發必須在整體設計完成後再開始增量或並行。
l 對於編碼人員經驗較少狀況下建議不要採用敏捷或迭代等生命週期模型。
l 增量、迭代和原型能夠綜合使用,但每一次增量或迭代都必須有明確的交付和出口準則。