軟體工程之開發模型
1. 瀑布模型
該模型是以文件作為驅動，一級一級的進行的開發，每乙個階段完成都會有乙個文件產生，根據該文件在進行下乙個階段的開發，在開發過程中，使用者看不見系統式什麼樣，只有開發完成的時候，系統才會整體提交。
優點：提供了按階段劃分的檢查點，當前階段完成後可以只關注後面的階段。適合於功能和效能明確、完整、無重大變化的軟體開發。大部分系統軟體具有這些特性。
缺點：缺乏對付變化（這裡的變化既有客戶需求的變化，也有開發時技術的變化）的機制，使得開發完成後對軟體公升級維護帶來較大的困難。缺乏靈活性，無法解決需求不明確模糊這樣的問題。
2. 原型模型
原型模型的主要思想是原型模型通過向使用者提供原型獲取使用者的反饋，使開發出的軟體能夠真正反映使用者的需求。同時，原型模型採用逐步求精的方法完善原型，使得原型能夠「快速」開發，避免了像瀑布模型一樣在冗長的開發過程中難以對使用者的反饋作出快速的響應。相對瀑布模型而言，原型模型更符合人們開發軟體的習慣，使目前較流行的一種實用軟體生存期模型。
優點：開發人員和使用者在「原型」上達成一致。這樣一來，可以減少設計中的錯誤和開發中的風險，也減少了對使用者培訓的時間，而提高了系統的實用、正確性以及使用者的滿意程度。縮短了開發周期，加快了工程進度。降低成本。
缺點：當告訴使用者，還必須重新生產該產品時，使用者是很難接受的。這往往給工程繼續開展帶來不利因素。不宜利用原型系統作為最終產品。採用原型模型開發系統，使用者和開發者必須達成一致：原型被建造僅僅是使用者用來定義需求，之後便部分或全部拋起，最終的軟體是要充分考慮了質量和可維護性等方面之後才被開發。
3. 增量模型
增量模型融合了瀑布模型的基本成分（重複應用）和原型實現的迭代特徵，該模型採用隨著日程時間的進展而交錯的線性序列，每乙個線性序列產生軟體的乙個可發布的「增量」。當使用增量模型時，第1個增量往往是核心的產品，即第1個增量實現了基本的需求，但很多補充的特徵還沒有發布。客戶對每乙個增量的使用和評估都作為下乙個增量發布的新特徵和功能，這個過程在每乙個增量發布後不斷重複，直到產生了最終的完善產品。
優點：採用增量模型的優點是人員分配靈活，剛開始不用投入大量人力資源。如果核心產品很受歡迎，則可增加人力實現下乙個增量。當配備的人員不能在設定的期限內完成產品時，它提供了一種先推出核心產品的途徑。這樣即可先發布部分功能給客戶，對客戶起到鎮靜劑的作用。此外，增量能夠有計畫地管理技術風險。
缺點：由於各個構件是逐漸併入已有的軟體體系結構中的，所以加入構件必須不破壞已構造好的系統部分，這需要軟體具備開放式的體系結構。在開發過程中，需求的變化是不可避免的。增量模型的靈活性可以使其適應這種變化的能力大大優於瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而是軟體過程的控制失去整體性。如果增量包之間存在相交的情況且未很好處理，則必須做全盤系統分析，這種模型將功能細化後分別開發的方法較適應於需求經常改變的軟體開發過程。
4. 螺旋模型
螺旋模型採用一種週期性的方法來進行系統開發。這會導致開發出眾多的中間版本。該模型是快速原型法，以進化的開發方式為中心，在每個專案階段使用瀑布模型法。螺旋模型基本做法是在「瀑布模型」的每乙個開發階段前引入乙個非常嚴格的風險識別、風險分析和風險控制，它把軟體專案分解成乙個個小專案。每個小專案都標識乙個或多個主要風險，直到所有的主要風險因素都被確定。
優點：設計上的靈活性,可以在專案的各個階段進行變更。客戶始終參與每個階段的開發,保證了專案不偏離正確方向以及專案的可控性。
缺點：建設週期長，而軟體技術發展比較快，所以經常出現軟體開發完畢後，和當前的技術水平有了較大的差距，無法滿足當前使用者需求。
5. 噴泉模型
噴泉模型是一種以使用者需求為動力，以物件為驅動的模型，主要用於採用物件技術的軟體開發專案。該模型認為軟體開發過程自下而上週期的各階段是相互迭代和無間隙的特性。軟體的某個部分常常被重複工作多次，相關物件在每次迭代中隨之加入漸進的軟體成分。無間隙指在各項活動之間無明顯邊界，如分析和設計活動之間沒有明顯的界限。噴泉模型不像瀑布模型那樣，需要分析活動結束後才開始設計活動，設計活動結束後才開始編碼活動。該模型的各個階段沒有明顯的界限，開發人員可以同步進行開發。
優點：可以提高軟體專案開發效率，節省開發時間，適應於物件導向的軟體開發過程。
缺點：由於噴泉模型在各個開發階段是重疊的，因此在開發過程中需要大量的開發人員，因此不利於專案的管理。此外這種模型要求嚴格管理文件，使得審核的難度加大，尤其是面對可能隨時加入各種資訊、需求與資料的情況。
軟體工程 開發模型軟體工程 開發模型
瀑布模式 螺旋模型 快速原型模式 增量模式 噴泉模型 演化模型 特點 推遲實現的觀點 質量保證 缺點 限制條件 優點 缺點 很難讓使用者確信這種演化方法的結果是可以控制的.建設週期長,而軟體技術發展比較快,所以經常出現軟體開發完畢後,和當前的技術水平有了較大的差距,無法滿足當前使用者需求.核心 在於...
軟體工程 開發模型
為了指導軟體開發，可以用不同的方式將軟體生命週期中的所有開發活動組織組織起來從而形成不同的開發模型。瀑布模型嚴格遵守軟體生命週期各階段的固定順序 計畫 分析 設計 程式設計 測試和維護，上一階段完成才能進入到下一階段，整個模型像乙個飛流直下的瀑布一下，如圖所示 特點 缺點 限制條件 優點 缺點 核心...
軟體工程 開發模型
前一階段完成後,才能開始後一階段 前一階段的輸出文字為後一階段的輸入文字 推遲實現的觀點 質量保證 每個階段必須交付出合格的文件 對文件進行審核 懼怕使用者測試中的反饋,懼怕需求變更 過於理想化缺乏靈活性 適合於大規模軟體專案 執行風險分析將大大影響專案的利潤,進行風險分析就毫無意義 軟體開發人員應...