軟體開發模型有哪些

A. 最新的軟體開發模型有哪些

我C,你是不是老師布置作業你來這邊找

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

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

C. 軟體開發模式有哪些

. 邊做邊改模型（Build-and-Fix Model）

好吧，其實現在許多產品實際都是使用的「邊做邊改」模型來開發的，特別是很多小公司產品周期壓縮的太短。在這種模型中，既沒有規格說明，也沒有經過設計，軟體隨著客戶的需要一次又一次地不斷被修改。

在這個模型中，開發人員拿到項目立即根據需求編寫程序，調試通過後生成軟體的第一個版本。在提供給用戶使用後，如果程序出現錯誤，或者用戶提出新的要求，開發人員重新修改代碼，直到用戶和測試等等滿意為止。

這是一種類似作坊的開發方式，邊做邊改模型的優點毫無疑問就是前期出成效快。

對編寫邏輯不需要太嚴謹的小程序來說還可以對付得過去，但這種方法對任何規模的開發來說都是不能令人滿意的，其主要問題在於：

• 缺少規劃和設計環節，軟體的結構隨著不斷的修改越來越糟，導致無法繼續修改；

• 忽略需求環節，給軟體開發帶來很大的風險；

• 沒有考慮測試和程序的可維護性，也沒有任何文檔，軟體的維護十分困難。

2. 瀑布模型（Waterfall Model）

瀑布模型是一種比較老舊的軟體開發模型，1970年溫斯頓·羅伊斯提出了著名的「瀑布模型」，直到80年代都還是一直被廣泛採用的模型。

瀑布模型將軟體生命周期劃分為制定計劃、需求分析、軟體設計、程序編寫、軟體測試和運行維護等六個基本活動，並且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。

在瀑布模型中，軟體開發的各項活動嚴格按照線性方式進行，當前活動接受上一項活動的工作結果，實施完成所需的工作內容。當前活動的工作結果需要進行驗證，如驗證通過，則該結果作為下一項活動的輸入，繼續進行下一項活動，否則返回修改。

瀑布模型優點是嚴格遵循預先計劃的步驟順序進行，一切按部就班比較嚴謹。

瀑布模型強調文檔的作用，並要求每個階段都要仔細驗證。但是，這種模型的線性過程太理想化，已不再適合現代的軟體開發模式，幾乎被業界拋棄，其主要問題在於：

• 各個階段的劃分完全固定，階段之間產生大量的文檔，極大地增加了工作量；

• 由於開發模型是線性的，用戶只有等到整個過程的末期才能見到開發成果，從而增加了開發的風險；

• 早期的錯誤可能要等到開發後期的測試階段才能發現，進而帶來嚴重的後果。

• 各個軟體生命周期銜接花費時間較長，團隊人員交流成本大。

• 瀑布式方法在需求不明並且在項目進行過程中可能變化的情況下基本是不可行的。

3. 迭代模型（stagewise model）

迭代模型（也被稱作迭代增量式開發或迭代進化式開發）是一種與傳統的瀑布式開發相反的軟體開發過程，它彌補了傳統開發方式中的一些弱點，具有更高的成功率和生產率。

在迭代式開發方法中，整個開發工作被組織為一系列的短小的、固定長度（如3周）的小項目，被稱為一系列的迭代。每一次迭代都包括了需求分析、設計、實現與測試。採用這種方法，開發工作可以在需求被完整地確定之前啟動，並在一次迭代中完成系統的一部分功能或業務邏輯的開發工作。再通過客戶的反饋來細化需求，並開始新一輪的迭代。

教學中，對迭代和版本的區別，可理解如下： 迭代一般指某版本的生產過程，包括從需求分析到測試完成； 版本一般指某階段軟體開發的結果，一個可交付使用的產品。

與傳統的瀑布模型相比較，迭代過程具有以下優點：

• 降低了在一個增量上的開支風險。如果開發人員重復某個迭代，那麼損失只是這一個開發有誤的迭代的花費。

• 降低了產品無法按照既定進度進入市場的風險。通過在開發早期就確定風險，可以盡早來解決而不至於在開發後期匆匆忙忙。

• 加快了整個開發工作的進度。因為開發人員清楚問題的焦點所在，他們的工作會更有效率。

• 由於用戶的需求並不能在一開始就作出完全的界定，它們通常是在後續階段中不斷細化的。因此，迭代過程這種模式使適應需求的變化會更容易些。因此復用性更高

4. 快速原型模型（Rapid Prototype Model）

快速原型模型的第一步是建造一個快速原型，實現客戶或未來的用戶與系統的交互，用戶或客戶對原型進行評價，進一步細化待開發軟體的需求。通過逐步調整原型使其滿足客戶的要求，開發人員可以確定客戶的真正需求是什麼；第二步則在第一步的基礎上開發客戶滿意的軟體產品。

顯然，快速原型方法可以克服瀑布模型的缺點，減少由於軟體需求不明確帶來的開發風險，具有顯著的效果。

快速原型的關鍵在於盡可能快速地建造出軟體原型，一旦確定了客戶的真正需求，所建造的原型將被丟棄。因此，原型系統的內部結構並不重要，重要的是必須迅速建立原型，隨之迅速修改原型，以反映客戶的需求。

快速原型模型有點整合「邊做邊改」與「瀑布模型」優點的意味。

5、增量模型（Incremental Model）

與建造大廈相同，軟體也是一步一步建造起來的。在增量模型中，軟體被作為一系列的增量構件來設計、實現、集成和測試，每一個構件是由多種相互作用的模塊所形成的提供特定功能的代碼片段構成。

增量模型在各個階段並不交付一個可運行的完整產品，而是交付滿足客戶需求的一個子集的可運行產品。整個產品被分解成若干個構件，開發人員逐個構件地交付產品，這樣做的好處是軟體開發可以較好地適應變化，客戶可以不斷地看到所開發的軟體，從而降低開發風險。但是，增量模型也存在以下缺陷：

• 由於各個構件是逐漸並入已有的軟體體系結構中的，所以加入構件必須不破壞已構造好的系統部分，這需要軟體具備開放式的體系結構。

• 在開發過程中，需求的變化是不可避免的。增量模型的靈活性可以使其適應這種變化的能力大大優於瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而是軟體過程的控制失去整體性。

在使用增量模型時，第一個增量往往是實現基本需求的核心產品。核心產品交付用戶使用後，經過評價形成下一個增量的開發計劃，它包括對核心產品的修改和一些新功能的發布。這個過程在每個增量發布後不斷重復，直到產生最終的完善產品。

例如，使用增量模型開發字處理軟體。可以考慮，第一個增量發布基本的文件管理、編輯和文檔生成功能，第二個增量發布更加完善的編輯和文檔生成功能，第三個增量實現拼寫和文法檢查功能，第四個增量完成高級的頁面布局功能。

6. 螺旋模型（Spiral Model）

1988年，巴利·玻姆(Barry Boehm)正式發表了軟體系統開發的「螺旋模型」，它將瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析，特別適合於大型復雜的系統。

螺旋模型沿著螺線進行若干次迭代，圖中的四個象限代表了以下活動：

• 制定計劃：確定軟體目標，選定實施方案，弄清項目開發的限制條件；

• 風險分析：分析評估所選方案，考慮如何識別和消除風險；

• 實施工程：實施軟體開發和驗證；

• 客戶評估：評價開發工作，提出修正建議，制定下一步計劃。

螺旋模型由風險驅動，強調可選方案和約束條件從而支持軟體的重用，有助於將軟體質量作為特殊目標融入產品開發之中。但是，螺旋模型也有一定的限制條件，具體如下：

• 螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，並做出相關反應是不容易的，因此，這種模型往往適應於內部的大規模軟體開發。

• 如果執行風險分析將大大影響項目的利潤，那麼進行風險分析毫無意義，因此，螺旋模型只適合於大規模軟體項目。

• 軟體開發人員應該擅長尋找可能的風險，准確地分析風險，否則將會帶來更大的風險

一個階段首先是確定該階段的目標，完成這些目標的選擇方案及其約束條件，然後從風險角度分析方案的開發策略，努力排除各種潛在的風險，有時需要通過建造原型來完成。如果某些風險不能排除，該方案立即終止，否則啟動下一個開發步驟。最後，評價該階段的結果，並設計下一個階段。

7. 敏捷軟體開發 (Agile development)

敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中，軟體項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特徵。換言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，並分別完成，在此過程中軟體一直處於可使用狀態。

敏捷開發小組主要的工作方式可以歸納為：作為一個整體工作； 按短迭代周期工作； 每次迭代交付一些成果，關注業務優先順序，檢查與調整。

敏捷軟體開發要注意項目規模，規模增長，團隊交流成本就上去了，因此敏捷軟體開發暫時適合不是特別大的團隊開發，比較適合一個組的團隊使用。

8. 演化模型（evolutionary model）

主要針對事先不能完整定義需求的軟體開發。用戶可以給出待開發系統的核心需求，並且當看到核心需求實現後，能夠有效地提出反饋，以支持系統的最終設計和實現。軟體開發人員根據用戶的需求，首先開發核心系統。當該核心系統投入運行後，用戶試用之，完成他們的工作，並提出精化系統、增強系統能力的需求。軟體開發人員根據用戶的反饋，實施開發的迭代過程。第一迭代過程均由需求、設計、編碼、測試、集成等階段組成，為整個系統增加一個可定義的、可管理的子集。

在開發模式上採取分批循環開發的辦法，每循環開發一部分的功能，它們成為這個產品的原型的新增功能。於是，設計就不斷地演化出新的系統。 實際上，這個模型可看作是重復執行的多個「瀑布模型」。

「演化模型」要求開發人員有能力把項目的產品需求分解為不同組，以便分批循環開發。這種分組並不是絕對隨意性的，而是要根據功能的重要性及對總體設計的基礎結構的影響而作出判斷。有經驗指出，每個開發循環以六周到八周為適當的長度。

9. 噴泉模型（fountain model, (面向對象的生存期模型, 面向對象（Object Oriented,OO）模型））

噴泉模型與傳統的結構化生存期比較，具有更多的增量和迭代性質，生存期的各個階段可以相互重疊和多次反復，而且在項目的整個生存期中還可以嵌入子生存期。就像水噴上去又可以落下來，可以落在中間，也可以落在最底部。

10. 智能模型（四代技術（4GL）)

智能模型擁有一組工具（如數據查詢、報表生成、數據處理、屏幕定義、代碼生成、高層圖形功能及電子表格等），每個工具都能使開發人員在高層次上定義軟體的某些特性，並把開發人員定義的這些軟體自動地生成為源代碼。這種方法需要四代語言（4GL）的支持。4GL不同於三代語言，其主要特徵是用戶界面極端友好，即使沒有受過訓練的非專業程序員，也能用它編寫程序；它是一種聲明式、互動式和非過程性編程語言。4GL還具有高效的程序代碼、智能預設假設、完備的資料庫和應用程序生成器。目前市場上流行的4GL（如Foxpro等）都不同程度地具有上述特徵。但4GL目前主要限於事務信息系統的中、小型應用程序的開發。

11. 混合模型（hybrid model）

過程開發模型又叫混合模型（hybrid model），或元模型（meta-model）,把幾種不同模型組合成一種混合模型，它允許一個項目能沿著最有效的路徑發展，這就是過程開發模型（或混合模型）。實際上，一些軟體開發單位都是使用幾種不同的開發方法組成他們自己的混合模型。

D. 軟體開發中有哪幾種過程模型

• 1.瀑布模型

  瀑布模型的特點是：

  階段間具有順序性和依賴性，前一階段結束後才能開始後一階段的工作，前一階段的輸出是厚意階段的輸入；推遲實現觀點，盡可能推遲程序的物理實現；強調質量保證觀點，每個階段必須完成規定的文檔，每個階段結束前完成文檔以便及早改正錯誤。

  優點：

  （1）原理簡單，容易掌握。

  （2）各階段間都有驗證和確認環節，以便進行質量管理。

  （3）主要用於支持結構化方法

  缺點：

  （1）缺乏靈活性，不能適應用戶的需求變化。

  （2）缺乏演化性，返回上一級的開發需要付出十分高昂的代價

  （3）是線性的軟體開發模型，回溯性差。

  使用場合：

  （1）適合於軟體需求比較明確或很少變化，且開發人員可以一次性獲取到全部需求的場合

  （2）適合開發技術比較成熟，工程管理比較嚴格的場合

  （3）一般用於低風險的項目，適合開發人員具有豐富的經驗。

  

E. 軟體設計模式主要有哪幾種

軟體設計模式主要有以下三大類共23種：

一、創建型模式：

1、工廠方法模式工廠方法模式的創建是因為簡單工廠模式有一個問題，在簡單工廠模式中類的創建依賴工廠類，如果想要拓展程序，必須對工廠類進行修改，這違背了開閉原則，所以就出現了工廠方法模式，只需要創建一個工廠介面和多個工廠實現類。

2、抽象工廠模式抽象工廠模式是提供一個創建一系列相關或相互依賴對象的介面，而無需指定它們具體的類。區別於工廠方法模式的地方，工廠方法模式是創建一個工廠，可以實現多種對象；而抽象工廠模式是提供一個抽象工廠介面，裡面定義多種工廠，每個工廠可以生產多種對象。

3、單例模式單例模式能保證一個類僅有一個實例，並提供一個訪問它的全局訪問點，同時在類內部創造單一對象，通過設置許可權，使類外部無法再創造對象。單例對象能保證在一個JVM中，該對象只有一個實例存在。

4、建造者模式建造者模式是將一個復雜的構建與其表示相分離，使得同樣的構建過程可以創建不同的表示。在程序當中就是將一些不會變的基本組件，通過builder來進行組合，構建復雜對象，實現分離。

5、原型模式：原型模式是用原型實例指定創建對象的種類，並且通過拷貝這些原型創建新的對象。其實就是將對象復制了一份並返還給調用者，對象需繼承Cloneable並重寫clone方法。原型模式的思想就是將一個對象作為原型，對其進行復制、克隆，產生一個和原對象類似的新對象。

二、結構型模式：

1、適配器模式適配器模式是使得原本由於介面不兼容而不能一起工作的那些類可以一起工作，銜接兩個不兼容、獨立的介面的功能，使得它們能夠一起工作，適配器起到中介的作用。

2、裝飾模式：裝飾器模式是動態地給一個對象添加一些額外的職責，給一個對象增加一些新的功能，要求裝飾對象和被裝飾對象實現同一個介面，裝飾對象持有被裝飾對象的實例。除了動態的增加，也可以動態的撤銷，要做到動態的形式，不可以用繼承實現，因為繼承是靜態的。

3、代理模式代理模式是為其他對象提供一種代理以控制對這個對象的訪問，也就是創建類的代理類，間接訪問被代理類的過程中，對其功能加以控制。

4、外觀模式外觀模式是為子系統中的一組介面提供一個一致的界面，外觀模式定義了一個高層介面，這個介面使得這一子系統更加容易使用。

5、橋接模式橋接模式是將抽象部分與實現部分分離，使它們都可以獨立的變化。橋接模式就是把事物和其具體實現分開，使他們可以各自獨立的變化（突然聯想到了mvc模式）。

6、組合模式：組合模式是將對象組合成樹形結構以表示"部分-整體"的層次結構，組合模式使得用戶對單個對象和組合對象的使用具有一致性。

7、享元模式：享元模式是運用共享技術有效地支持大量細粒度的對象。享元模式的主要目的是實現對象的共享，即共享池，當系統中對象多的時候可以減少內存的開銷，重用現有的同類對象，若未找到匹配的對象，則創建新對象，這樣可以減少對象的創建，降低系統內存，提高效率。

三、行為型模式：

1、策略模式：

策略模式是定義一系列的演算法,把它們一個個封裝起來, 並且使它們可相互替換，且演算法的變化不會影響到使用演算法的客戶。

2、模版方法模式：

模板方法模式是定義一個操作中的演算法的骨架，而將一些步驟延遲到子類中。該模式就是在一個抽象類中，有一個主方法，再定義1...n個方法，可以是抽象的，也可以是實際的方法，定義一個類，繼承該抽象類，重寫抽象方法，通過調用抽象類，實現對子類的調用。

模板方法使得子類可以不改變一個演算法的結構即可重定義該演算法的某些特定步驟，將一些固定步驟、固定邏輯的方法封裝成模板方法。調用模板方法即可完成那些特定的步驟。

3、觀察者模式：

觀察者模式是定義對象間的一種一對多的依賴關系，當一個對象的狀態發生改變時，所有依賴於它的對象都得到通知並被自動更新。

也就是當被觀察者狀態變化時，通知所有觀察者，這種依賴方式具有雙向性，在QQ郵箱中的郵件訂閱和RSS訂閱，當用戶瀏覽一些博客時，經常會看到RSS圖標，簡單來說就是當訂閱了該文章，如果後續有更新，會及時通知用戶。這種現象即是典型的觀察者模式。

4、迭代器模式：

迭代器模式是提供一種方法順序訪問一個聚合對象中各個元素, 而又無須暴露該對象的內部表示。

在Java當中，將聚合類中遍歷各個元素的行為分離出來，封裝成迭代器，讓迭代器來處理遍歷的任務；使簡化聚合類，同時又不暴露聚合類的內部，在我們經常使用的JDK中各個類也都是這些基本的東西。

5、責任鏈模式：

責任鏈模式是避免請求發送者與接收者耦合在一起，讓多個對象都有可能接收請求，將這些對象連接成一條鏈，並且沿著這條鏈傳遞請求，直到有對象處理它為止。有多個對象，每個對象持有對下一個對象的引用，這樣就會形成一條鏈，請求在這條鏈上傳遞，直到某一對象決定處理該請求。

6、命令模式：

命令模式是將一個請求封裝成一個對象，從而使發出者可以用不同的請求對客戶進行參數化。模式當中存在調用者、接收者、命令三個對象，實現請求和執行分開；調用者選擇命令發布，命令指定接收者。

7、備忘錄模式：

備忘錄模式是在不破壞封裝性的前提下，捕獲一個對象的內部狀態，並在該對象之外保存這個狀態。創建一個備忘錄類，用來存儲原始類的信息；同時創建備忘錄倉庫類，用來存儲備忘錄類，主要目的是保存一個對象的某個狀態，以便在適當的時候恢復對象，也就是做個備份。

8、狀態模式：

狀態模式是允許對象在內部狀態發生改變時改變它的行為。對象具有多種狀態，且每種狀態具有特定的行為。

9、訪問者模式：

訪問者模式主要是將數據結構與數據操作分離。在被訪問的類裡面加一個對外提供接待訪問者的介面，訪問者封裝了對被訪問者結構的一些雜亂操作，解耦結構與演算法，同時具有優秀的擴展性。通俗來講就是一種分離對象數據結構與行為的方法。

10、中介者模式：

中介者模式是用一個中介對象來封裝一系列的對象交互，中介者使各對象不需要顯式地相互引用，從而使其耦合鬆散，而且可以獨立地改變它們之間的交互。

11、解釋器模式：

解釋器模式是給定一個語言，定義它的文法表示，並定義一個解釋器，這個解釋器使用該標識來解釋語言中的句子，基本也就用在這個范圍內，適用面較窄，例如：正則表達式的解釋等。

(5)軟體開發模型有哪些擴展閱讀：

軟體設計的概念以及意義：

軟體設計模式是對軟體設計經驗的總結，是對軟體設計中反復出現的設計問題的成功解決方案的描述。為了記錄這些成功的設計經驗並方便以後使用，軟體設計模式通常包含 4 個基本要素：模式名稱、問題、解決方案以及效果。

模式名稱實際上就是一個幫助記憶的名稱，是用於軟體設計的技術術語，有助於設計者之間的交流。

問題描述了設計者所面臨的設計場景，用於告訴設計者在什麼情況下使用該模式。

解決方案描述了設計的細節，通常會給出方案的原理圖示（例如 UML 的類圖，序列圖等，也可能是一些示意圖）及相關文字說明，如果可能，還會給出一些代碼實例，以便對解決方案的深入理解。

效果描述了設計方案的優勢和劣勢，這些效果通常面向軟體的質量屬性，例如，可擴展性、可復用性等。

軟體設計模式的重要意義在於設計復用。設計模式可以使設計者更加方便地借鑒或直接使用已經過證實的成功設計方案，而不必花費時間進行重復設計。一些設計模式甚至提供了顯示的類圖設計及代碼實例，為設計的文檔化及軟體的開發提供了直接的支持。

F. 軟體的開發模式有哪些

‍‍1.瀑布模型 ： 1970年溫斯頓·羅伊斯（Winston Royce）提出了著名的「瀑布模型」，直到80年代早期，它一直是唯一被廣泛採用的軟體開發模型。
2.迭代模型 ： 在某種程度上，開發迭代是一次完整地經過所有工作流程的過程：需求、分析設計、實施和測試工作流程。實質上，它類似小型的瀑布式項目。RUP認為，所有的階段都可以細分為迭代。每一次的迭代都會產生一個可以發布的產品，這個產品是最終產品的一個子集。
3.敏捷開發模型 ： 是一種從1990年代開始逐漸引起廣泛關注的一些新型軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。相對於「非敏捷」，更強調程序員團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文檔更有效）、頻繁交付新的軟體版本。能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟體開發中人的作用。敏捷建模（Agile Modeling，AM）的價值觀包括了XP的四個價值觀：溝通、簡單、反饋、勇氣，此外，還擴展了第五個價值觀：謙遜。
4.螺旋模型：螺旋模型是一種演化軟體開發過程模型，它兼顧了快速原型的迭代的特徵以及瀑布模型的系統化與嚴格監控。螺旋模型最大的特點在於引入了其他模型不具備的風險分析，使軟體在無法排除重大風險時有機會停止，以減小損失。同時，在每個迭代階段構建原型是螺旋模型用以減小風險的途徑。螺旋模型更適合大型的昂貴的系統級的軟體應用。
5.快速原型模型：快速原型模型需要迅速建造一個可以運行的軟體原型 ，以便理解和澄清問題，使開發人員與用戶達成共識，最終在確定的客戶需求基礎上開發客戶滿意的軟體產品。 快速原型模型允許在需求分析階段對軟體的需求進行初步而非完全的分析和定義，快速設計開發出軟體系統的原型，該原型向用戶展示待開發軟體的全部或部分功能和性能；用戶對該原型進行測試評定，給出具體改進意見以豐富細化軟體需求；開發人員據此對軟體進行修改完善，直至用戶滿意認可之後，進行軟體的完整實現及測試、維護。

G. 軟體工程的開發模型主要有什麼模型

原型法適用於用戶沒有確定其需求的明確內容的時候。他先是根據已給的和分析的需求，建立一個原始模型，這是一個可以修改的模型（在聲明周期法中，需求分析一般不再多修改）。在軟體開發的各個階段都把有關信息相互反饋，直至模型的修改，使模型趨於完善。在各個過程中，用戶的參與和決策加強了，最終的結果更適合用戶的要求。這種原型技術有分為三類：拋棄式、演化式和遞增式。原型法成敗的關鍵及效率的高低關鍵在於模型的建立和建模的速度。 原型法的優點是：可以解決在產品開發早期需求不確定的問題（不確定性、二義性、不完整性、含糊性等），可以明確並完善需求、探索設計選擇方案、發展為最終產品。 原型法的缺點也是顯而易見的，需要在正式的代碼開發之前進行必要的原型開發，在某種程度上增加了工作量，尤其採用拋棄型原型，更是如此。
正確的有 1 2 3 5 6 7 9 10

H. 軟體開發有哪些模式

快速原型模型：（需要迅速造一個可以運行的軟體原型，以便理解和澄清問題）

快速原型模型允許在需求分析階段對軟體的需求進行初步的非完全的分析和定義，快速設計開發出軟體系統的原型（展示待開發軟體的全部或部分功能和性能
（過程：用戶對該原型進行測試評定，給出具體改善的意見以及豐富的細化軟體需求，開發人員進行修改完善）

優點：
克服瀑布模型的缺點，減少由於軟體需求不明確帶來的開發風險
缺點：
A、 所選用的開發技術和工具不一定符合主流的發展
B、 快速建立起來的系統加上連續的修改可能會造成 產品質量底下

增量模型：（採用隨著日程時間的進展而交錯的線性序列，每一個線性徐磊產生軟體的一個可發布的「增量」，第一個增量往往就是核心的產品）

與其他模型共同之處：它與原型實現模型和其他演化方法一樣，本質都是迭代

與原型實現模型不同之處：它強調每一個增量均發布一個可操作產品，（它不需要等到所有需求都出來，只要摸個需求的增量包出來即可進行開發）

優點：
1、 人員分配靈活，一開始不需要投入大量人力資源
2、 當配備人員不能在限定的時間內完成產品時，它可以提供一種先推出核心產品的途徑，可現發布部分功能給用戶（對用戶起鎮靜作用）
3、 增量能夠有計劃的管理技術風險

缺點：
1、 如果增量包之間存在相交的情況且未很好處理，則必須做全盤系統分析

註：
這種模型將功能細化後分別開發的方法較適應於需求經常改變的軟體開發過程

原型模型：（樣品模型，採用逐步求精的方法完善原型）

主要思想：
先借用已有系統作為原型模型，通過「樣品」不斷改進，使得最後的產品就是用戶所需要的。原型模型通過向用戶提供原型獲取用戶的反饋，使開發出的軟體能夠真正反映用戶的需求，

採用方法：
原型模型採用逐步求精的方法完善原型，使得原型能夠「快速」開發，避免了像瀑布模型一樣在冗長的開發過程中難以對用戶的反饋作出快速的響應

優點：

(1）開發人員和用戶在「原型」上達成一致。這樣一來，可以減少設計中的錯誤和開發中的風險，也減少了對用戶培訓的時間，而提高了系統的實用、正確性以及用戶的滿意程度。

（2）縮短了開發周期，加快了工程進度。
（3）降低成本。
缺點：
1、當重新生產該產品時，難以讓用戶接收，給工程繼續開展帶來不利因素。
2、不宜利用原型系統作為最終產品。採用原型模型開發系統，用戶和開發者必須達成一致：

噴泉模型：（以用戶需求為動力，以對象為驅動的模型，主要用於採用對象技術的軟體開發項目）

它認為軟體開發過程自下而上周期的各階段是相互迭代和無間隙的特性
相互迭代：軟體的摸個部分常常被重復工作多次，相關對象在每次迭代中隨之加入漸進的軟體成分
無間隙:它在各項活動之間沒有明顯邊界（如分析和設計活動之間<由於對象概念的應用，表達分析，設計，實現等活動只用對象類和關系>）

優點：
1、 可以提高軟體項目開發效率，節省開發時間，適應於面向對象的軟體開發過程

不便之處：
1、由於噴泉模型在各個開發階段是重疊的，因此在開發過程中需要大量的開發人員，因此不利於項目的管理。
2、這種模型要求嚴格管理文檔，使得審核的難度加大，尤其是面對可能隨時加入各種信息、需求與資料的情況

螺旋模型：（適合用於需求經常變化的項目<適合於大型復雜的系統>）

它主要是風險分析與評估，沿著螺線進行若干次迭代，
過程：
1、 制定計劃：確定軟體目標，選定實施方案，弄清項目開發的限制條件
2、 風險分析：分析評估所選方案，考慮如何識別和消除風險
3、 實施工程：實施軟體開發和驗證；
4、 客戶評估：評價開發工作，提出修正建議，制定下一步計劃。

優點：
1、 它由風險驅動，強調可選方案和約束條件從而支持軟體的重用，有助於將軟體質量作為特殊目標融入產品開發中
缺點：
1、 難以讓用戶確信這種煙花方法的結果是可以控制的
2、 建設周期長（而軟體技術發展比較快，所以經常會出現軟體開發完畢後，和當前的技術水平有很大的差距，無法滿足當前用戶的需求）
3、 除非軟體開發人員擅長尋找可能的風險，准確的分析風險，否則將會帶來更大的風險

瀑布模型：（從本質來講，瀑布模型是一個軟體開發架構,重復應用）
（核心思想：按工序將問題化簡，將功能的實現與設計分開，便於分工協作，採用結構化的分析與設計方法將邏輯實現與物理實現分開，依照軟體生命周期自上而下，相互銜接的次序<如同瀑布流水逐級下落>）

缺點：
1、 在項目各個階段之間極少有反饋，各個階段的劃分完全固定，階段之間產生大量的文檔，增加了工作量
2、 用戶只有在項目生命周期的後期才能看到結果，增加了開發的風險
3、 需要過多的強制完成日期和里程碑來跟蹤各個項目的階段
4、 在每個階段都會產生循環反饋
（如果有信息未被覆蓋或是發現問題了，必須返回到上一個階段<甚至更前面的活動>並進行適當的修改,只有當上一階段都被確認後才進行下一階段）
5、 早期的錯誤可能要等到開發後期的測試階段才能發現，進而帶來嚴重的後果

優點：
1、 為項目提供了按階段分的檢查點
2、 當完成一個階段後，只需要去關注後續階段
3、 可在迭代模型中應用瀑布模型

按照瀑布模型的階段劃分，軟體測試可以分為單元測試，集成測試，系統測試

註：由於每個階段都會產生循環反饋，對於經常變化的項目而言，瀑布模型毫無價值，這種模型的線性過程太理想化，已不適合現代的軟體開發模式

I. 常用的開發模型有哪些

1. 邊做邊改模型

許多產品都是使用邊做邊改模型來開發的。在這種模型中，既沒有規格說明，也沒有經過設計，軟體隨著客戶的需要一次又一次地不斷被修改。

在這個模型中，開發人員拿到項目立即根據需求編寫程序，調試通過後生成軟體的第一個版本。在提供給用戶使用後，如果程序出現錯誤，或者用戶提出新的要求，開發人員重新修改代碼，直到用戶滿意為止。

這是一種類似作坊的開發方式，對編寫幾百行的小程序來說還不錯，但這種方法對任何規模的開發來說都是不能令人滿意的，其主要問題在於缺少規劃和設計環節，軟體的結構隨著不斷的修改越來越糟，導致無法繼續修改。並且沒有考慮測試和程序的可維護性，也沒有任何文檔，軟體的維護十分困難。

2. 瀑布模型

瀑布模型中，將軟體生命周期劃分為制定計劃、需求分析、軟體設計、程序編寫、軟體測試和運行維護等六個基本活動，並且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。

在瀑布模型中，軟體開發的各項活動嚴格按照線性方式進行，當前活動接受上一項活動的工作結果，實施完成所需的工作內容。當前活動的工作結果需要進行驗證，如果驗證通過，則該結果作為下一項活動的輸入，繼續進行下一項活動，否則返回修改。

3. 快速原型模型

快速原型模型的第一步是建造一個快速原型，實現客戶或未來的用戶與系統的交互，用戶或客戶對原型進行評價，進一步細化待開發軟體的需求。通過逐步調整原型使其滿足客戶的要求，開發人員可以確定客戶的真正需求是什麼；第二步則在第一步的基礎上開發客戶滿意的軟體產品。

顯然，快速原型方法可以克服瀑布模型的缺點，減少由於軟體需求不明確帶來的開發風險，具有顯著的效果。快速原型的關鍵在於盡可能快速地建造出軟體原型，一旦確定了客戶的真正需求，所建造的原型將被丟棄。因此，原型系統的內部結構並不重要，重要的是必須迅速建立原型，隨之迅速修改原型，以反映客戶的需求。

4 RUP模型

RUP模型是一個面向對象軟體工程的通用業務流程。它描述了一系列相關的軟體工程流程，它們具有相同的結構，即相同的流程構架。RUP具有兩個軸，一個軸是時間軸，這是動態的。另一個軸是工作流軸，這是靜態的。在時間軸上，RUP劃分了四個階段：初始階段、細化階段、構造階段和發布階段。每個階段都使用了迭代的概念。RUP 匯集現代軟體開發中多方面的最佳經驗，並為適應各種項目及組織的需要提供了靈活的形式。作為一個商業模型，它具有非常詳細的過程指導和模板。但是同樣由於該模型比較復雜，因此在模型的掌握上需要花費比較大的成本。尤其對項目管理者提出了比較高的要求。

5. 增量模型

又稱演化模型。與建造大廈相同，軟體也是一步一步建造起來的。在增量模型中，軟體被作為一系列的增量構件來設計、實現、集成和測試，每一個構件是由多種相互作用的模塊所形成的提供特定功能的代碼片段構成。

增量模型在各個階段並不交付一個可運行的完整產品，而是交付滿足客戶需求的一個子集的 可運行產品。整個產品被分解成若干個構件，開發人員逐個構件地交付產品，這樣做的好處是軟體開發可以較好地適應變化，客戶可以不斷地看到所開發的軟體，從而降低開發風險。

6 智能模型

智能模型擁有一組工具（如數據查詢、報表生成、數據處理、屏幕定義、代碼生成、高層圖形功能及電子表格等），每個工具都能使開發人員在高層次上定義軟體的某些特性，並把開發人員定義的這些軟體自動地生成為源代碼。

這種方法需要四代語言（4GL）的支持。4GL不同於三代語言，其主要特徵是用戶界面極端友好，即使沒有受過訓練的非專業程序員，也能用它編寫程序；它是一種聲明式、互動式和非過程性編程語言。4GL還具有高效的程序代碼、智能預設假設、完備的 資料庫和應用程序生成器。但4GL目前主要限於事務信息系統的中、小型應用程序的開發。

作為一家專業的軟體開發公司，開運聯合通過軟體與服務的結合，軟體與產業的結合，服務了航天、軍工、鐵路、醫療等領域的眾多頂級客戶。公司研發的Moa非結構化資料庫是國內唯一一款非結構化資料庫軟體，旨在為信息系統提供可擴展的高性能數據存儲解決方案，更適合大數據處理和數據挖掘。

J. 軟體開發模型有幾種

與建造大廈相同，軟體也是一步一步建造起來的。在增量模型中，軟體被作為一系列的增量構件來設計、實現、集成和測試，每一個構件是由多種相互作用的模塊所形成的提供特定功能的代碼片段構成. 增量模型在各個階段並不交付一個可運行的完整產品，而是交付滿足客戶需求的一個子集的可運行產品。整個產品被分解成若干個構件，開發人員逐個構件地交付產品，這樣做的好處是軟體開發可以較好地適應變化，客戶可以不斷地看到所開發的軟體，從而降低開發風險。但是，增量模型也存在以下缺陷： （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）,把幾種不同模型組合成一種混合模型，它允許一個項目能沿著最有效的路徑發展，這就是過程開發模型（或混合模型）。實際上，一些軟體開發單位都是使用幾種不同的開發方法組成他們自己的混合模型。 各種模型的比較 每個軟體開發組織應該選擇適合於該組織的軟體開發模型，並且應該隨著當前正在開發的特定產品特性而變化，以減小所選模型的缺點，充分利用其優點，下表列出了幾種常見模型的優缺點。