採用哪種軟體工程過程模型

『壹』 軟體過程模型的過程模型

它有時也稱為傳統生存周期模型或瀑布模型。它提出了軟體開發的系統化的、順序的方法。其流程從系統開始，隨後是需求分析、設計、編碼、測試、支持。這種模型是最早也是應用最廣泛的軟體過程模型(雖然這種模型會引起「堵賽狀態」)。
缺點：
1、實際的項目大部分情況難以按照該模型給出的順序進行，而且這種模型的迭代是間接的，這很容易由微小的變化而造成大的混亂。
2、 經常情況下客戶難以表達真正的需求，而這種模型卻要求如此，這種模型是不歡迎具有二義性問題存在的。
3、 客戶要等到開發周期的晚期才能看到程序運行的測試版本，而在這時發現大的錯誤時，可能引起客戶的驚慌，而後果也可能是災難性的。
4、採用這種線性模型，會經常在過程的開始和結束時碰到等待其他成員完成其所依賴的任務才能進行下去，有可能花在等待的時間比開發的時間要長。我們稱之為「堵賽狀態」。
優點：
1、它提供了一個模板，這個模板使得分析、設計、編碼、測試和支持的方法可以在該摸板下有一個共同的指導。
2、雖然有不少缺陷但比在軟體開發中隨意的狀態要好得多。 從需求收集開始，開發者和客戶在一起定義軟體的總體目標，標識已知的需求並且規劃出需要進一步定義的區域。然後是「快速設計」，它集中於軟體中那些對客戶可見的部分的表示，這將導致原型的創建，並由客戶評估並進一步精化待開發軟體的需求。逐步調整原型使其滿足客戶的需求，這個過程是迭代的。其流程從聽取客戶意見開始、隨後是建造/修改原型、客戶測試運行原型、然後回頭往復循環直到客戶對原型滿意為止。由於這種模型可以讓客戶快速的感受到實際的系統（雖然這個系統不帶有任何質量的保證），所以客戶和開發者都比較喜歡這種過程模型（對於那些僅僅用來演示軟體功能的公司而言或從來不考慮軟體質量和不害怕長期維護的公司而言）。
缺點：
1、沒有考慮軟體的整體質量和長期的可維護性。
2、大部分情況是不合適的操作演算法被採用目的為了演示功能，不合適的開發工具被採用僅僅為了它的方便，還有不合適的操作系統被選擇等等。
3、由於達不到質量要求產品可能被拋棄，而採用新的模型重新設計。
優點：
1、如果客戶和開發者達成一致協議：原型被建造僅為了定義需求，之後就被拋棄或者部分拋棄， 那麼這種模型很合適了。
2、迷惑客戶搶占市場，這是一個首選的模型。 這是一個增量型的軟體開發過程模型，強調極短的開發周期，它是線性模型的一個「高速」變種，通過使用構件的建造方法贏得了快速開發。如果需求理解的好而且約束了項目的范圍，利用這種模型可以很快的創建出功能完善的「信息系統」。其流程從業務建模開始，隨後是數據建模、過程建模、應用生成、測試及反復。RAD過程強調的是復用，復用已有的或開發可復用的構件。實際上RAD採用第四代技術。
缺點：
1、只能用於信息系統。
2、對於較大的項目需要足夠的人力資源去建造足夠的RAD組。
3、開發者和客戶必須在很短的時間完成一系列的需求分析， 任何一方配合不當都會導致RAD項目失敗。
4、這種模型對模塊化要求比較高，如果有哪一功能不能被模塊化，那麼建造RAD所需要的構件就會有問題。
5、技術風險很高的情況下不適合這種模型。
優點：
1、開發速度快，質量有保證。
2、對信息系統特別有效。 這種模型融合了線性順序模型的基本成份和原型實現模型的迭代特徵。增量模型採用隨著日程時間的進展而交錯的線性序列。每一個線性序列產生軟體的一個可發布的「增量」。當使用增量模型時，第一個增量往往是核心的產品，也就是說第一個增量實現了基本的需求，但很多補充的特徵還沒有發布。客戶對每一個增量的使用和評估，都做為下一個增量發布的新特徵和功能。這個過程在每一個增量發布後不斷從復，直到產生了最終的完善產品。增量模型強調每一個增量均發布一個可操作的產品。
缺點：
1、至始至終開發者和客戶糾纏在一起，直到完全版本出來。
優點：
1、人員分配靈活，剛開始不用投入大量人力資源，當核心產品很受歡迎時，可增加人力實現下一個增量。
2、當配備的人員不能在設定的期限內完成產品時，它提供了一種先推出核心產品的途徑，這樣就可以先發布部分功能給客戶，對客戶起到鎮靜劑的作用。
3、具有一定的市場。 這是一個演化軟體過程模型，它將原型實現的迭代特徵和線性順序模型中控制的和系統化的方面結合起來。使得軟體的增量版本的快速開發成為可能。在螺旋模型中，軟體開發是一系列的增量發布。在每一個迭代中，被開發系統的更加完善的版本逐步產生。螺旋模型被劃分為若干框架活動，也稱為任務區域。典型地，有3到6個任務區域：
1、客戶交流：建立開發者和客戶之間有效通信所需要的任務。
2、計劃：定義資源、進度、及其它相關項目信息所需要的任務。
3、風險分析：評估技術的及管理的風險所需要的任務。
4、工程：建立應用的一個或多個表示說需要的任務。
5、構造及發布：構造、測試、安裝和提供用戶支持所需要的任務。
6、客戶評估：基於對在工程階段產生的或在安裝階段實現的軟體表示的評估，獲得客戶反饋所需要的任務。
這是一個相對較新的模型，它的功效還需要經歷若干年的使用方能確定下來。
缺點：
1、需要相當的風險分析評估的專門技術，且成功依賴於這種技術。
2、很明顯一個大的沒有被發現的風險問題，將會導致問題的發生，可能導致演化的方法失去控制。
3、這種模型相對比較新，應用不廣泛，其功效需要進一步的驗證。
優點：
1、對於大型系統及軟體的開發，這種模型是一個很好的方法。開發者和客戶能夠較好地對待和理解每一個演化級別上的風險。 螺旋模型提出了強調客戶交流的一個框架活動。該活動的目標是從客戶處誘導項目需求。在理想情況下，開發者簡單地詢問客戶需要什麼,而客戶提供足夠的細節進行下去。不幸的是這種情形很少發生。在現實中，客戶和開發者進入一個談判過程，客戶被要求在成本和應市之間的約束下平衡功能、性能、和其它產品或系統特徵。最好的談判追求「雙贏」結果，也就是說通過談判客戶獲得大部份系統的功能，而開發者則獲得現實的和可達到的預算和時限。對客戶的交流定義了下面的活動：
1、系統或子系統的關鍵「風險承擔者」的標識。
2、風險承擔者的「贏條件」的確定。
3、風險承擔者的贏條件談判，以將它們協調為一組滿足各方考慮的雙贏條件。
缺點：
1、需要額外的談判技巧。
優點：
1、客戶和開發者達到一種平衡。 這種模型關注於多個任務的並發執行，表示為一系列的主要技術活動、任務及它們的相關狀態。並發過程模型是由客戶要求、管理決策、評審結果驅動的。該模型不是將軟體工程活動限定為一個順序的事件序列，而是定義了一個活動網路。網路上的每一個活動均可於其它活動同時發生。這種模型可以提供一個項目的當前狀態的准確視圖。
缺點：暫時無
優點：
1、可用於所有類型的軟體開發，而對於客戶/伺服器結構更加有效。
2、可以隨時查閱到開發的狀態。 面向對象的技術為軟體工程的基於構件的過程模型提供了技術框架。面向對象模型強調了類的創建、類的封裝了的數據、操縱該數據的演算法。一般來講經過合適的設計和實現，面向對象的類可以在不同的應用及基於計算機的系統的體系結構中復用。基於構件的開發模型融合了螺旋模型的許多特徵，它本質上是演化形的，要求軟體創建的迭代方法。然而基於構件的開發模型是利用預先包裝好的軟體構件（有時成為類）來構造應用。
開發活動從候選類的標識開始，這一步是通過檢查將被應用系統操縱的數據及用於實現該操縱的演算法來完成的。相關的數據和演算法被封裝成一個類。
缺點：
1、過分依賴於構件，構件庫的質量影響著產品質量。
優點：
1、構件可復用。提高了開發效率。
2、採用了面向對象的技術。 形式化方法模型包含了一組活動，他們導致了計算機軟體的數學規約。形式化方法使得軟體工程師們能夠通過應用一個嚴格的數學符號體系來規約、開發、和驗證基於計算機的系統。 這種方法的一個變種，稱為凈室軟體工程，已經被一些組織所採用。在開發中使用形式化方法時，它們提供了一種機制，能夠消除使用其它軟體過程模型難以克服的很多問題。二義性、不完整性、不一致性能被更容易地發現和糾正，而不是通過專門的評審，是通過對應用的數學分析。 形式化方法提供了可以產生無缺陷軟體的承諾。
缺點：
1、開發費用昂貴（對開發人員需要多方面的培訓），而且需要的時間較長。
2、不能將這種模型作為對客戶通信的機制，因為客戶對這些數學語言一無所知。
3、還不流行。
優點：
1、形式化規約可直接作為程序驗證的基礎，可以盡早的發現和糾正錯誤（包括那些其它情況下不能發現的錯誤）。
2、開發出來的軟體具有很高的安全性和健壯性，特別適合安全部門或者軟體錯誤會造成經濟損失的開發者。
3、具有開發無缺陷軟體的承諾。 一系列的軟體工具的使用，是第四代技術的特點。這些工具有一個共同的特點：能夠使軟體工程師們在較高級別上規約軟體的某些特徵，然後根據開發者的規約自動生成源代碼。我們知道，軟體在越高的級別上被規約，就越能被快速的建造出程序。軟體工程的
4GT模型集中於規約軟體的能力：使用特殊的語言形式或一種採用客戶可以理解的術語描述待解決問題的圖形符號體系。和其它模型一樣，4GT也是從需求收集這一步開始的，要將一個4GT實現變成最終產品，開發者還必須進行徹底的測試、開發有意義的文檔，並且同樣要完成其它模型中同樣要求的所有集成活動。總而言之，4GT已經成為軟體工程的一個重要方法。特別是和基於構件的開發模型結合起來時，4GT模型可能成為當前軟體開發的主流模型！
缺點：
1、用工具生成的源代碼可能是「低效」的。
2、生成的大型軟體的可維護性還令人懷疑。
3、在某些情況下可能需要更多的時間。
優點：
1、縮短了軟體開發時間，提高了建造軟體的效率。
2、對很多不同的應用領域提供了一種可行性途徑和解決方案

『貳』 軟體工程過程包含哪幾個過程

軟體工程(SoftWare Engineering)的框架可概括為：目標、過程和原則。 (1)軟體工程目標：生產具有正確性、可用性以及開銷合宜的產品。正確性指軟體產品達到預期功能的程度。可用性指軟體基本結構、實現及文檔為用戶可用的程度。開銷合宜是指軟體開發、運行的整個開銷滿足用戶要求的程度。這些目標的實現不論在理論上還是在實踐中均存在很多待解決的問題，它們形成了對過程、過程模型及工程方法選取的約束。 (2)軟體工程過程：生產一個最終能滿足需求且達到工程目標的軟體產品所需要的步驟。軟體工程過程主要包括開發過程、運作過程、維護過程。它們覆蓋了需求、設計、實現、確認以及維護等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義，又稱軟體需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟體系統結構，包括子系統、模塊以及相關層次的說明、每一模塊的介面定義。詳細設計產生程序員可用的模塊說明，包括每一模塊中數據結構說明及加工描述。實現活動把設計結果轉換為可執行的程序代碼。確認活動貫穿於整個開發過程，實現完成後的確認，保證最終產品滿足用戶的要求。維護活動包括使用過程中的擴充、修改與完善。伴隨以上過程，還有管理過程、支持過程、培訓過程等。 (3)軟體工程的原則是指圍繞工程設計、工程支持以及工程管理在軟體開發過程中必須遵循的原則。

『叄』 軟體工程中五種模型的並發過程及區別

過程就不介紹了，條件不一樣，過程也常常不一樣。介紹一下幾種模型的特徵：
瀑布模型：適用於簡單的、復雜度低的項目；
增量模型：適用於需求明確，但項目資源受限的項目；
螺旋形：適用於需求不明確的項目。一般是用於項目集管理，開發不會使用這種模型，因為不好控制項目的投資節點和時間節點。
其它的模型基本上都是這3種的衍生模式和組合模型，還有一些模式是學術討論用的，由於忽視資金對項目的影響，基本上是不適用的。

『肆』 軟體工程中軟體過程的噴泉模型是什麼啊

噴泉模型是一種以用戶需求為動力，以對象為驅動的模型，主要用於採用對象技術的軟體開發項目。該模型認為軟體開發過程自下而上周期的各階段是相互迭代和無間隙的特性。軟體的某個部分常常被重復工作多次，相關對象在每次迭代中隨之加入漸進的軟體成分。無間隙指在各項活動之間無明顯邊界，如分析和設計活動之間沒有明顯的界限，由於對象概念的引入，表達分析、設計、實現等活動只用對象類和關系，從而可以較為容易地實現活動的迭代和無間隙，使其開發自然地包括復用。
噴泉模型不像瀑布模型那樣，需要分析活動結束後才開始設計活動，設計活動結束後才開始編碼活動。該模型的各個階段沒有明顯的界限，開發人員可以同步進行開發。其優點是可以提高軟體項目開發效率，節省開發時間，適應於面向對象的軟體開發過程。由於噴泉模型在各個開發階段是重疊的，因此在開發過程中需要大量的開發人員，因此不利於項目的管理。此外這種模型要求嚴格管理文檔，使得審核的難度加大，尤其是面對可能隨時加入各種信息、需求與資料的情況。
http://ke..com/view/756139.htm

『伍』 軟體開發模型有哪幾種各有什麼特點

軟體開發模型(Software Development Model)是指軟體開發全部過程、活動和任務的結構框架。軟體開發包括需求、設計、編碼和測試等階段，有時也包括維護階段。軟體開發模型能清晰、直觀地表達軟體開發全過程，明確規定了要完成的主要活動和任務，用來作為軟體項目工作的基礎。對於不同的軟體系統，可以採用不同的開發方法、使用不同的程序設計語言以及各種不同技能的人員參與工作、運用不同的管理方法和手段等，以及允許採用不同的軟體工具和不同的軟體工程環境。軟體工程的主要環節包括人員管理、項目管理、需求分析、系統設計、程序設計、測試、維護等，如圖所示。軟體開發模型是對軟體過程的建模，即用一定的流程將各個環節連接起來，並可用規范的方式操作全過程，好比工廠的生產線。

8.混合模型（hybrid model）過程開發模型又叫混合模型（hybrid model），或元模型（meta-model）,把幾種不同模型組合成一種混合模型，它允許一個項目能沿著最有效的路徑發展，這就是過程開發模型（或混合模型）。實際上，一些軟體開發單位都是使用幾種不同的開發方法組成他們自己的混合模型。各種模型的比較每個軟體開發組織應該選擇適合於該組織的軟體開發模型，並且應該隨著當前正在開發的特定產品特性而變化，以減小所選模型的缺點，充分利用其優點，下表列出了幾種常見模型的優缺點。各種模型的優點和缺點：模型優點缺點瀑布模型文檔驅動系統可能不滿足客戶的需求快速原型模型關注滿足客戶需求可能導致系統設計差、效率低，難於維護增量模型開發早期反饋及時，易於維護需要開放式體系結構，可能會設計差、效率低螺旋模型風險驅動風險分析人員需要有經驗且經過充分訓練

9.RUP模型（迭代模型）

RUP（Rational Unified Process）模型是Rational公司提出的一套開發過程模型，它是一個面向對象軟體工程的通用業務流程。它描述了一系列相關的軟體工程流程，它們具有相同的結構，即相同的流程構架。RUP 為在開發組織中分配任務和職責提供了一種規范方法，其目標是確保在可預計的時間安排和預算內開發出滿足最終用戶需求的高品質的軟體。RUP具有兩個軸，一個軸是時間軸，這是動態的。另一個軸是工作流軸，這是靜態的。在時間軸上，RUP劃分了四個階段：初始階段、細化階段、構造階段和發布階段。每個階段都使用了迭代的概念。在工作流軸上，RUP設計了六個核心工作流程和三個核心支撐工作流程，核心工作流軸包括：業務建模工作流、需求工作流、分析設計工作流、實現工作流、測試工作流和發布工作流。核心支撐工作流包括：環境工作流、項目管理工作流和配置與變更管理工作流。RUP 匯集現代軟體開發中多方面的最佳經驗，並為適應各種項目及組織的需要提供了靈活的形式。作為一個商業模型，它具有非常詳細的過程指導和模板。但是同樣由於該模型比較復雜，因此在模型的掌握上需要花費比較大的成本。尤其對項目管理者提出了比較高的要求。它具有如下特點：（1）增量迭代，每次迭代都遵循瀑布模型能夠在前期控制好和解決風險；（2）模型的復雜化，需要項目管理者具有較強的管理能力。

10.IPD模型

IPD（Integrated Proct Development）流程是由IBM提出來的一套集成產品開發流程，非常適合於復雜的大型開發項目，尤其涉及到軟硬體結合的項目。

IPD從整個產品角度出發，流程綜合考慮了從系統工程、研發（硬體、軟體、結構工業設計、測試、資料開發等）、製造、財務到市場、采購、技術支援等所有流程。是一個端到端的流程。在IPD流程中總共劃分了六個階段（概念階段、計劃階段、開發階段、驗證階段、發布階段和生命周期階段），四個個決策評審點（概念階段決策評審點、計劃階段決策評審點、可獲得性決策評審點和生命周期終止決策評審點）以及六個技術評審點。

IPD流程是一個階段性模型，具有瀑布模型的影子。該模型通過使用全面而又復雜的流程來把一個龐大而又復雜的系統進行分解並降低風險。一定程度上，該模型是通過流程成本來提高整個產品的質量並獲得市場的佔有。由於該流程沒有定義如何進行流程回退的機制，因此對於需求經常變動的項目該流程就顯得不大適合了。並且對於一些小的項目，也不是非常適合使用該流程。

『陸』 請給出軟體工程統一過程模型圖

， 並請：1)闡述統一過程模型的內容和特點; 2)簡要談談軟體工程過程模型化描述的作用。

『柒』 一個軟體組織是否應該對它所有的軟體開發都採用同一種軟體過程模型

軟體開發模型(Software Development Model)是指軟體開發全部過程、活動和任務的結構框架。軟體開發包括需求、設計、編碼和測試等階段，有時也包括維護階段。 軟體開發模型能清晰、直觀地表達軟體開發全過程，明確規定了要完成的主要活動和任務，用來作為軟體項目工作的基礎。對於不同的軟體系統，可以採用不同的開發方法、使用不同的程序設計語言以及各種不同技能的人員參與工作、運用不同的管理方法和手段等，以及允許採用不同的軟體工具和不同的軟體工程環境。

『捌』 總結歸納主要的軟體工程模型，並任意選定其中的一種過程模式，介紹其特點及你對該模型的理解。

主要的軟體過程模型有：瀑布模型，演化模型（如增量模型、原型模型、螺旋模型）、噴泉模型、基於構件的開發模型和形式方法模型等。
瀑布模型（waterfall model）是1970年有W.Royce提出的，它給出了軟體生存周期活動的固定順序，上一階段的活動完成後向下一階段過渡，最終得到所開發的軟體產品。瀑布模型如下圖所示，有時也稱為軟體生存周期模型。

瀑布模型中，上一階段的活動完成並經過評審後才能開始下一階段的活動，其特徵是：
（1）接受上一階段的結果作為本階段活動的輸入。
（2）依據上一階段活動的結果實施本階段應完成的活動。
（3）對本階段的活動進行評審。
（4）將本階段活動的結果作為輸出，傳遞給下一階段。
瀑布模型是最早出現的也是應用最廣泛的過程模型，對確保軟體開發的順利進行、提高軟體項目的質量和開發效率起到重要作用。
在大量的實踐過程中，瀑布模型也逐漸暴露出它的不足。首先，客戶常常難以清楚地描述所有的要求，而且在開發過程中，用戶的需求也常常會有所變化，使得不少軟體的需求存在著不確定性；在某個活動中發現的錯誤常常是由前一階段活動的錯誤引起的，為了改正這一錯誤必須回到前一階段，這就導致了瀑布的倒流，也就是說，實際的軟體開發很少能按瀑布模型的順序沒有迴流地順流而下。其次，瀑布模型使得客戶在測試完成以後才能看到真正可運行的軟體，此時，如果發現不滿足客戶需求的問題（由於需求不確定性），那麼修改軟體的代價是巨大的。
不是任何軟體都可採用瀑布模型的，瀑布模型適合於結構化方法，也就是面向過程的軟體開發方法。軟體項目或產品選擇瀑布模型必須滿足下列條件：在開發時間內需求沒有或很少變化；分析設計人員應對應用領域很熟悉；低風險項目（對目標、環境很熟悉）；用戶使用環境很穩定；用戶除提出需求以外，很少參與開發工作。