軟件工程中開發(fā)模型的優(yōu)缺點及適用場合

1、邊做邊改模型瀑布模型快速原型模型增量模型螺旋模型思想不斷的修正版本不斷的 供用 戶使用，如果出現(xiàn) 錯誤或是 新的需求又不 斷的修改代 碼。軟件的開發(fā)嚴格的按照 線 性方式進行，當前活 動的工 作結果，實施完 成所需要的 工作結果需 要驗證，如果驗 證通過， 則結果作為下一項 活動 的輸入，繼續(xù)。否則返 回?？焖僭湍Ｐ屠玫氖?原 型輔助軟件開發(fā)的一 種思 想。經過簡單、快 速的分析， 快速實現(xiàn)一 個原型，用戶與 開發(fā)人 員在試用原型過程 中加 強通信與反饋， 通過反 復評價和改進原型， 減 少誤 解，彌補漏洞，適 應變化， 最終提高軟件 質里。軟件被看作是一系列的 增 量構建來設計、實現(xiàn)、

2、集 成和測試，每一個構 建由 多種相互作用的模 塊所形 成的提供特定功 能呢的代 碼片段構成。開發(fā)出一部分就向用戶 展 示一部分，及早的發(fā) 現(xiàn)問 題。先開發(fā)一個原 型模型 的軟件，完成模 型的主要 功能。展示給 用戶征求意 見。這種模型的每一個周期 都 包括需求定乂、風險 分 析、工程實現(xiàn)和評審 4 個 階段，由這 4 個階 段進行 迭代。優(yōu)占 八' 、在提供給用戶使用后， 如果 程序出現(xiàn)錯誤，或 者用戶提 出新的要求， 開發(fā)人員重新 修改代 碼，直到用戶滿意為 止。一種有效的管理視圖。每項開發(fā)活動均處于一 個 質量環(huán)節(jié)。文檔驅動， 以項 目階段評審和文檔 控制為手 段有效的對整 個開

3、發(fā)過程進 行指導。（ 1）快速模型克服瀑布模 型的特點， 減少由于軟 件需 求不明確帶來的開 發(fā)風險， 具有顯著的效 果。 （2）能 快速吸引用 戶，從而搶占市 場。1? 縮短時間2. 開發(fā)人員與用戶可以 通過原型充分的交流；3. 有利于用戶的培訓和 開發(fā)的同步。4. 加入構建必須不破壞 已構造好的體系結構。5. 模型的靈活性可以使 其適應需求的變化（1）可以在項目的各個階 段進行變更（ 2）可以分 段來構建大型系統(tǒng)，使 成 本計算變得簡單、容 易。 （3）用戶參與開發(fā)， 保 證項目不偏離正確方 向。缺少規(guī)劃和設計環(huán)節(jié)。 忽略 需求環(huán)節(jié)，風險大。 周期長費用高。缺乏靈活性，太過于理 想 化。如

4、果開發(fā)其中， 客戶難 以明確需求，需（ 1 ） 沒有考慮軟件的整體 質量和長期的可維護 性。（ 2）這種模型在大部很容易退化為邊做邊改 模 型（1）不能讓用戶確信這 種演化方法結果是可控 的。（ 2）建設周期長缺占 八' 、求錯誤在后期就難以糾 正。分情況下是不適合的， 采 用該模型往往是為了 演示 功能的需要或匕的 方便 性。 （ 3）由于達不到 質量 要求可能被拋棄， 而采用 新的模型重新設 計。適 用 場 合對于需求非常簡單 和容易明白，軟件期 望的功能行為容易 定 義，實現(xiàn)的成功或 失敗容易檢驗的工 程 可以使用這種模 型。適合于客戶的需求較明 確的情況下。用戶需求不明確、小型

5、 或是交互型式的系統(tǒng)、 大型系統(tǒng)的某些部分技術風險較大、用戶需求較為穩(wěn)定的軟件系統(tǒng)適合于大型復雜的系統(tǒng)迭代模型噴泉模型敏捷模型混合模式思想整個開發(fā)工作被組織為一系 列的 短小的、固定長度（如 3 周）的小項 目， 被稱為一系列的迭代。 每一次迭 代都包括了需求分 析、設計、實 現(xiàn)與測試軟件開發(fā)過程的各個階段是 相互 迭代的、無間歇的。軟 件的某個 部分常常被重復工 作多次，相關 對象在每次迭 代中加入漸近的軟 件成分。把一個大項目分為多個相互 聯(lián) 系，但也可獨立運行的小 項目， 并分別完成，在此過 程中軟件一 直處于可使用狀 態(tài)。把幾種不同模型組合成一種 混合 模型，它允許一個項目 能沿著最 有效的路徑發(fā)展， 這就是過程開 發(fā)模型（或混 合模型）。實際 上，一些軟件 開發(fā)單位都是使用 幾種不同 的開發(fā)方法組成他們自 己的 混合模型。優(yōu)占 八 ' 、降低風險、得到早期用戶反 饋、 持續(xù)的測試和集成、使 用變更、 提咼復用性可以提高軟件項目開發(fā)效 率，節(jié) 省開發(fā)時間。緊密協(xié)作、面對面的溝通給企業(yè)管理者和開發(fā)者提供 了一 個舞臺，使每個模型的 長處得到 發(fā)揮缺點項目風險可能會很高不利于項目管理文檔少對企業(yè)的管理和