軟體過程模型有哪些

Ⅰ 什麼是軟體過程建模

這個問題好像是軟體工程里的

Ⅱ 軟體過程模型的介紹

所謂軟體過程模型就是一種開發策略，這種策略針對軟體工程的各個階段提供了一套范形，使工程的進展達到預期的目的。對一個軟體的開發無論其大小，我們都需要選擇一個合適的軟體過程模型，這種選擇基於項目和應用的性質、採用的方法、需要的控制，以及要交付的產品的特點。一個錯誤模型的選擇，將迷失我們的開發方向。對於下面的模型，希望能夠給開發者們一個參考和一點啟示。

Ⅲ 軟體開發模型有哪幾種各有什麼特點

軟體開發模型(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） 在開發過程中，需求的變化是不可避免的。增量模型的靈活性可以使其適應這種變化的能力大大優於瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而是軟體過程的控制失去整體性。 在使用增量模型時，第一個增量往往是實現基本需求的核心產品。核心產品交付用戶使用後，經過評價形成下一個增量的開發計劃，它包括對核心產品的修改和一些新功能的發布。這個過程在每個增量發布後不斷重復，直到產生最終的完善產品。 例如，使用增量模型開發字處理軟體。可以考慮，第一個增量發布基本的文件管理、編輯和文檔生成功能，第二個增量發布更加完善的編輯和文檔生成功能，第三個增量實現拼寫和文法檢查功能，第四個增量完成高級的頁面布局功能。 5.螺旋模型（Spiral Model） 1988年，Barry Boehm正式發表了軟體系統開發的"螺旋模型"，它將瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析，特別適合於大型復雜的系統。 螺旋模型沿著螺線進行若干次迭代，圖中的四個象限代表了以下活動： （1） 制定計劃：確定軟體目標，選定實施方案，弄清項目開發的限制條件； （3） 實施工程：實施軟體開發和驗證； （4） 客戶評估：評價開發工作，提出修正建議，制定下一步計劃。 螺旋模型由風險驅動，強調可選方案和約束條件從而支持軟體的重用，有助於將軟體質量作為特殊目標融入產品開發之中。但是，螺旋模型也有一定的限制條件，具體如下： （1） 螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，並做出相關反應是不容易的，因此，這種模型往往適應於內部的大規模軟體開發。 （2） 如果執行風險分析將大大影響項目的利潤，那麼進行風險分析毫無意義，因此，螺旋模型只適合於大規模軟體項目。 一個階段首先是確定該階段的目標，完成這些目標的選擇方案及其約束條件，然後從風險角度分析方案的開發策略，努力排除各種潛在的風險，有時需要通過建造原型來完成。如果某些風險不能排除，該方案立即終止，否則啟動下一個開發步驟。最後，評價該階段的結果，並設計下一個階段。 6.演化模型(incremental model) 主要針對事先不能完整定義需求的軟體開發。用戶可以給出待開發系統的核心需求，並且當看到核心需求實現後，能夠有效地提出反饋，以支持系統的最終設計和實現。軟體開發人員根據用戶的需求，首先開發核心系統。當該核心系統投入運行後，用戶試用之，完成他們的工作，並提出精化系統、增強系統能力的需求。軟體開發人員根據用戶的反饋，實施開發的迭代過程。第一迭代過程均由需求、設計、編碼、測試、集成等階段組成，為整個系統增加一個可定義的、可管理的子集。 在開發模式上採取分批循環開發的辦法，每循環開發一部分的功能，它們成為這個產品的原型的新增功能。於是，設計就不斷地演化出新的系統。 實際上，這個模型可看作是重復執行的多個「瀑布模型」。 「演化模型」要求開發人員有能力把項目的產品需求分解為不同組，以便分批循環開發。這種分組並不是絕對隨意性的，而是要根據功能的重要性及對總體設計的基礎結構的影響而作出判斷。有經驗指出，每個開發循環以六周到八周為適當的長度。 7.噴泉模型（fountain model, (面向對象的生存期模型, OO模型)） 噴泉模型與傳統的結構化生存期比較，具有更多的增量和迭代性質，生存期的各個階段可以相互重疊和多次反復，而且在項目的整個生存期中還可以嵌入子生存期。就像水噴上去又可以落下來，可以落在中間，也可以落在最底部。 8.智能模型(四代技術（4GL）) 智能模型擁有一組工具（如數據查詢、報表生成、數據處理、屏幕定義、代碼生成、高層圖形功能及電子表格等），每個工具都能使開發人員在高層次上定義軟體的某些特性，並把開發人員定義的這些軟體自動地生成為源代碼。這種方法需要四代語言（4GL）的支持。4GL不同於三代語言，其主要特徵是用戶界面極端友好，即使沒有受過訓練的非專業程序員，也能用它編寫程序；它是一種聲明式、互動式和非過程性編程語言。4GL還具有高效的程序代碼、智能預設假設、完備的資料庫和應用程序生成器。目前市場上流行的4GL（如Foxpro等）都不同程度地具有上述特徵。但4GL目前主要限於事務信息系統的中、小型應用程序的開發。 9.混合模型（hybrid model） 過程開發模型又叫混合模型（hybrid model），或元模型（meta-model）,把幾種不同模型組合成一種混合模型，它允許一個項目能沿著最有效的路徑發展，這就是過程開發模型（或混合模型）。實際上，一些軟體開發單位都是使用幾種不同的開發方法組成他們自己的混合模型。 各種模型的比較 每個軟體開發組織應該選擇適合於該組織的軟體開發模型，並且應該隨著當前正在開發的特定產品特性而變化，以減小所選模型的缺點，充分利用其優點，下表列出了幾種常見模型的優缺點。

Ⅳ 軟體測試過程模型主要有哪些

V模型
v模型在軟體測試方面，V模型是最廣為人知的模型，盡管很多富有實際經驗的測試人員還是不太熟悉V模型，或者其它的模型。V模型已存在了很長時間，和瀑布開發模型有著一些共同的特性，由此也和瀑布模型一樣地受到了批評和質疑。V模型中的過程從左到右，描述了基本的開發過程和測試行為。V模型的價值在於它非常明確地標明了測試過程中存在的不同級別，並且清楚地描述了這些測試階段和開發過程期間各階段的對應關系。局限性：把測試作為編碼之後的最後一個活動，需求分析等前期產生的錯誤直到後期的驗收測試才能發現。

W模型
W模型W模型由Evolutif公司提出，相對於V模型，W模型更科學。W模型是V模型的發展，強調的是測試伴隨著整個軟體開發周期，而且測試的對象不僅僅是程序，需求、功能和設計同樣要測試。測試與開發是同步進行的，從而有利於盡早地發現問題。W模型也有局限性。W模型和V模型都把軟體的開發視為需求、設計、編碼等一系列串列的活動，無法支持迭代、自發性以及變更調整。

X模型
X模型X模型的左邊描述的是針對單獨程序片段所進行的相互分離的編碼和測試，此後將進行頻繁的交接，通過集成最終成為可執行的程序，然後再對這些可執行程序進行測試。己通過集成測試的成品可以進行封裝並提交給用戶，也可以作為更大規模和范圍內集成的一部分。多根並行的曲線表示變更可以在各個部分發生。由圖中可見，X模型還定位了探索性測試，這是不進行事先計劃的特殊類型的測試，這一方式往往能幫助有經驗的測試人員在測試計劃之外發現更多的軟體錯誤。但這樣可能對測試造成人力、物力和財力的浪費，對測試員的熟練程度要求比較高。

H模型
H模型H模型中, 軟體測試過程活動完全獨立,貫穿於整個產品的周期,與其他流程並發地進行,某個測試點准備就緒時,就可以從測試准備階段進行到測試執行階段。軟體測試可以盡早的進行,並且可以根據被測物的不同而分層次進行。這個示意圖演示了在整個生產周期中某個層次上的一次測試「微循環」。圖中標注的其它流程可以是任意的開發流程,例如設計流程或者編碼流程。也就是說, 只要測試條件成熟了,測試准備活動完成了,測試執行活動就可以進行了。
H模型揭示了一個原理:軟體測試是一個獨立的流程,貫穿產品整個生命周期,與其他流程並發地進行。H模型指出軟體測試要盡早准備, 盡早執行。不同的測試活動可以是按照某個次序先後進行的,但也可能是反復的,只要某個測試達到准備就緒點,測試執行活動就可以開展。

Ⅵ 常見的軟體開發模型是什麼

演化模型、螺旋模型、噴泉模型、智能模型等。

軟體開發模型(Software Development Model)是指軟體開發全部過程、活動和任務的結構框架。軟體開發包括需求、設計、編碼和測試等階段，有時也包括維護階段。軟體開發模型能清晰、直觀地表達軟體開發全過程，明確規定了要完成的主要活動和任務，用來作為軟體項目工作的基礎。

最早出現的軟體開發模型是1970年W·Royce提出的瀑布模型。該模型給出了固定的順序，將生存期活動從上一個階段向下一個階段逐級過渡，如同流水下瀉，最終得到所開發的軟體產品，投入使用。

但計算拓廣到統計分析、商業事務等領域時，大多數程序採用高級語言(如FORTRAN、COBOL等)編寫。瀑布模式模型也存在著缺乏靈活性、無法通過並發活動澄清本來不夠確切的需求等缺點。

Ⅶ 軟體過程模型的總結

過程模型總分為五大類：
1.慣例過程模型。
2.瀑布模型(又叫作生命周期模型)。
3.增量過程模型: 包括增量模型、RAD模型。
4.演化過程模型: 包括 原型開發模型、螺旋模型、協同開發模型。
5.專用過程模型: 包括 基於構件的開發模型、形式化方法模型、面向方面的軟體開發模型。
(參考文獻:軟體工程-實踐者的研究方法 (美)Poger S.Pressman )

Ⅷ 軟體過程模型的過程模型

它有時也稱為傳統生存周期模型或瀑布模型。它提出了軟體開發的系統化的、順序的方法。其流程從系統開始，隨後是需求分析、設計、編碼、測試、支持。這種模型是最早也是應用最廣泛的軟體過程模型(雖然這種模型會引起「堵賽狀態」)。
缺點：
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、對很多不同的應用領域提供了一種可行性途徑和解決方案

Ⅸ 系統軟體適合使用哪些軟體過程模型

它有時也稱為傳統生存周期模型或瀑布模型。它提出了軟體開發的系統化的、順序的方法。其流程從系統開始，隨後是需求分析、設計、編碼、測試、支持。這種模型是最早也是應用最廣泛的軟體過程模型(雖然這種模型會引起「堵賽狀態」)。缺點：1、實際的項目大部分情況難以按照該模型給出的順序進行，而且這種模型的迭代是間接的，這很容易由微小的變化而造成大的混亂。2、 經常情況下客戶難以表達真正的需求，而這種模型卻要求如此，這種模型是不歡迎具有二義性問題存在的。3、 客戶要等到開發周期的晚期才能看到程序運行的測試版本，而在這時發現大的錯誤時，可能引起客戶的驚慌，而後果也可能是災難性的。4、採用這種線性模型，會經常在過程的開始和結束時碰到等待其他成員完成其所依賴的任務才能進行下去，有可能花在等待的時間比開發的時間要長。我們稱之為「堵賽狀態」。優點：1、它提供了一個模板，這個模板使得分析、設計、編碼、測試和支持的方法可以在該摸板下有一個共同的指導。2、雖然有不少缺陷但比在軟體
雖然有不少缺陷但比在軟體開發中隨意的狀態要好得多。 從需求收集開始，開發者和客戶在一起定義軟體的總體目標，標識已知的需求並且規劃出需要進一步定義的區域。然後是「快速設計」，它集中於軟體中那些對客戶可見的部分的表示，這將導致原型的創建，並由客戶評估並進一步精化待開發軟體的需求。逐步調整原型使其滿足客戶的需求，這個過程是迭代的。其流程從聽取客戶意見開始、隨後是建造/修改原型、客戶測試運行原型、然後回頭往復循環直到客戶對原型滿意為止。

Ⅹ 簡述各類軟體過程模型的特點

.瀑布模型

它提出了軟體開發的系統化的、順序的方法。其流程從系統開始，隨後是需求分析、設計、編碼、測試、支持。這種模型是最早也是應用最廣泛的軟體過程模型(雖然這種模型會引起「堵賽狀態」)。
優點：

1.它提供了一個模板，這個模板使得分析、設計、編碼、測試和支持的方法可以在該摸板下有一個共同的指導。
2.雖然有不少缺陷但比在軟體開發中隨意的狀態要好得多。
缺點：

1.實際的項目大部分情況難以按照該模型給出的順序進行，而且這種模型的迭代是間接的，這很容易由微小的變化而造成大的混亂。
2.經常情況下客戶難以表達真正的需求，而這種模型卻要求如此，這種模型是不歡迎具有二義性問題存在的。
3.客戶要等到開發周期的晚期才能看到程序運行的測試版本，而在這時發現大的錯誤時，可能引起客戶的驚慌，而後果也可能是災難性的。
4.採用這種線性模型，會經常在過程的開始和結束時碰到等待其他成員完成其所依賴的任務才能進行下去，有可能花在等待的時間比開發的時間要長。我們稱之為「堵賽狀態」。
適用范圍：

1. 用戶的需求非常清楚全面，且在開發過程中沒有或很少變化
2. 開發人員對軟體的應用領域很熟悉
3. 用戶的使用環境非常穩定
4. 開發工作對用戶參與的要求很低

顯著特點：

按工序將問題化簡，將功能的實現與設計分開，便於分工協作
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

2.增量模型

這種模型融合了線性順序模型的基本成份和原型實現模型的迭代特徵。增量模型採用隨著日程時間的進展而交錯的線性序列。每一個線性序列產生軟體的一個可發布的「增量」。當使用增量模型時，第一個增量往往是核心的產品，也就是說第一個增量實現了基本的需求，但很多補充的特徵還沒有發布。客戶對每一個增量的使用和評估，都做為下一個增量發布的新特徵和功能。這個過程在每一個增量發布後不斷從復，直到產生了最終的完善產品。增量模型強調每一個增量均發布一個可操作的產品。
優點：

1.採用增量模型的優點是人員分配靈活，剛開始不用投入大量人力資源
2.如果核心產品很受歡迎，則可增加人力實現下一個增量
3.可先發布部分功能給客戶，對客戶起到鎮靜劑的作用

缺點：

1.並行開發構件有可能遇到不能集成的風險，軟體必須具備開放式的體系結構
2.增量模型的靈活性可以使其適應這種變化的能力大大優於瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而是軟體過程的控制失去整體性

適用范圍：

1.進行已有產品升級或新版本開發，增量模型是非常適合的
2.對完成期限嚴格要求的產品，可以使用增量模型
3.對所開發的領域比較熟悉而且已有原型系統，增量模型也是非常適合的

顯著特點：

引進了增量包的概念，無須等到所有需求都出來，只要某個需求增量包出來即可進行開發
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

3.螺旋模型

這是一個演化軟體過程模型，它將原型實現的迭代特徵和線性順序模型中控制的和系統化的方面結合起來。使得軟體的增量版本的快速開發成為可能。在螺旋模型中，軟體開發是一系列的增量發布。在每一個迭代中，被開發系統的更加完善的版本逐步產生。螺旋模型被劃分為若干框架活動，也稱為任務區域

優點：

1.設計上的靈活性,可以在項目的各個階段進行變更
2.以小的分段來構建大型系統,使成本計算變得簡單容易
3.客戶始終參與每個階段的開發,保證了項目不偏離正確方向以及項目的可控性
4.隨著項目推進,客戶始終掌握項目的最新信息 , 從而他或她能夠和管理層有效地交互
5.客戶認可這種公司內部的開發方式帶來的良好的溝通和高質量的產品
缺點：

1.採用螺旋模型需要具有相當豐富的風險評估經驗和專門知識，在風險較大的項目開發中，如果未能夠及時標識風險，勢必造成重大損失
2.過多的迭代次數會增加開發成本，延遲提交時間
3.很難讓用戶確信這種演化方法的結果是可以控制的。建設周期長，而軟體技術發展比較快，所以經常出現軟體開發完畢後，和當前的技術水平有了較大的差距，無法滿足當前用戶需求
適用范圍：

對於新近開發，需求不明確的情況下，適合用螺旋模型進行開發，便於風險控制和需求變更，螺旋模型只適合於大規模的軟體項目
顯著特點：

引入了其他模型不具備的風險分析，使軟體在無法排除重大風險時有機會停止，以減小損失
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

4.RAD模型

快速應用開發(RAD)是一個線性順序的軟體開發模型，強調極短的開發周期。RAD 模型是線性順序模型的一個「高速」變種，通過使用基於構件的建造方法獲得了快速開發
優點：

1.開發速度快，質量有保證
2.對信息系統特別有效
缺點：

1.對大型項目而言，RAD需要足夠的人力資源
2.開發者和客戶都要實現承諾，否則將導致失敗
3.並非所有系統都適合：不能合理模塊化的系統、高性能需求並且要調整構件介面的系統均不適合
適用范圍：

1.不適合技術風險很高的開發，不適合系統需求是高性能，並且需要通過調整構件介面的方式來提高性能的產品開發。
2.適用於工期緊張，又可細分功能，還要有合適的構件
顯著特點：

使用基於構件的建造方法獲得了快速開發，使得一個開發組能夠在很短時間內(如60 到90 天)創建出「功能完善的系統」
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

5.迭代模型

迭代包括產生產品發布（穩定、可執行的產品版本）的全部開發活動和要使用該發布必需的所有其他外圍元素。在某種程度上，開發迭代是一次完整地經過所有工作流程的過程：需求分析、設計、實施和測試工作流程。實質上，它類似小型的瀑布式項目。RUP認為，所有的階段都可以細分為迭代。每一次的迭代都會產生一個可以發布的產品，這個產品是最終產品的一個子集
優點：

1.降低了在一個增量上的開支風險。如果開發人員重復某個迭代，那麼損失只是這一個開發有誤的迭代的花費
2.降低了產品無法按照既定進度進入市場的風險。通過在開發早期就確定風險，可以盡早來解決而不至於在開發後期匆匆忙忙
3.加快了整個開發工作的進度。因為開發人員清楚問題的焦點所在，他們的工作會更有效率
4.由於用戶的需求並不能在一開始就作出完全的界定，它們通常是在後續階段中不斷細化的。因此，迭代過程這種模式使適應需求的變化會更容易些
缺點：

在項目早期開發可能有所變化 ，需有一個高素質的項目管理者和一個高技術水平的開發團隊
適用范圍：

1.在項目開發早期需求可能有所變化
2.分析設計人員對應用領域很熟悉
3.高風險項目
4.用戶可不同程度地參與整個項目的開發過程
5.使用面向對象的語言或統一建模語言
6.使用CASE工具
7.具有高素質的項目管理者和軟體研發團隊

顯著特點：

能顯著減少風險