軟體工程開發模型迭代

1. 迭代模型的介紹

對眾多的開發模型和過程方法，及權威機構的看法，企業應選擇什麼樣的開發模型，應慎重對從以下幾方面進行考慮：
1、RUP雖然內容極其豐富，定義了選起、精化、構建、產品化4個階段和業務建模、需求、分析設計、實現、測試、部署等9個工種，提供了一大堆的文檔模板，但極易讓人誤解是重型的過程，實施推廣有一定難度。
2、再次，在質量管理方面：以實現系統架構、核心功能目標的迭代產品生的工作成果作為質量控制重點。每次迭代進行系統集成、系統測試，達到對軟體質量的持續驗證。每次系統測試，需要回歸測試前一次迭代遺留發現的問題。每次迭代發布的小版本組織客戶（包括內部客戶、外部客戶）進行評價，通過演示操作等方式，評價該次迭代是否達到預定的目標，並以此為依據來制定下一次迭代的目標。
3、最後，在其他方面：每次迭代成果須進行配置管理，版本控制很重要。在整個迭代過程中風險無處不在，建議每周作一次風險跟蹤。同時通過重點關注進度、工作量、滿意度、缺陷等數據收集，關注每次迭代情況。
總之，選擇一個合適的生命周期模型，並應用正確的方法，對於任何軟體項目的成功是至關重要。企業在選擇開發模型應從項目時間要求、需求明確程度、風險狀況等選擇合適的生命周期模型。 與傳統的瀑布模型相比較，迭代過程具有以下優點：
1）降低了在一個增量上的開支風險。如果開發人員重復某個迭代，那麼損失只是這一個開發有誤的迭代的花費。
2）降低了產品無法按照既定進度進入市場的風險。通過在開發早期就確定風險，可以盡早來解決而不至於在開發後期匆匆忙忙。
3）加快了整個開發工作的進度。因為開發人員清楚問題的焦點所在，他們的工作會更有效率。
4）由於用戶的需求並不能在一開始就作出完全的界定，它們通常是在後續階段中不斷細化的。因此，迭代過程這種模式使適應需求的變化會更容易些。

2. 迭代模型開發流程中sdv是啥意思

不同的J2EE項目開發流程：一個典型的J2EE項目通常應該使用哪一種開發流程呢？流行開發流程有很多種，應用比較廣泛的有：瀑布式、迭代式、以及RUP(RationalUnifiedProcess)。每一種都有其優點和不足，所以通常我們應該把它們結合起來而不是認定其中一個然後100%按著它的規范走。首先來看看每一種大致是什麼意思：[瀑布式]這種模式的流程強調在開始編碼和測試之前完成所有的需求分析和設計，這種模式歷史相當久遠，也很成熟，甚至到了今天，這種模式還是被廣泛的採用到絕大多數公司和項目中。採用這種模式開發的項目通常很大，並且需要較長時間交付。正因為如此，這些項目通常會有的風險：在業務需求不斷變化的今天，如果待開發的系統不能及時反應出這些需求的變化，最終開發出來的產品可能已經不是客戶真正需要的了。[迭代式]為了應對傳統瀑布式的開發在處理需求變更上的不足，近些年出現了一種全新的極限編程的概念。極限編程（XP）的核心思想在於：從長遠看，早期發現錯誤以及降低復雜度可以節約成本。極限編程強調我們將任務/系統細分為可以在較短周期解決的一個個子任務/模塊，並且強調測試、代碼質量和及早發現問題。通常，通過一個個短小的迭代周期，我們就可以獲得一個個階段性的進展，並且可以及時形成一個版本供用戶參考，以便及時對用戶可能的需求變更作出響應。[RUP]RUP的全稱是RationalUnifiedProcess，是一套定義得很完整的軟體工程模型。它強調編碼前的需求分析和設計，以及短迭代周期的開發和發布。它鼓勵團隊首先開發項目中風險最高的模塊，用的時間發現和應對問題，當設計需要變化時，它也能夠在一定程度上減輕一些重復工作。不過，因為RUP十分嚴謹，也比較具體，通常要完全跟著這個流程走也不是100%必要。下面我們來看看實際上我們應該採取什麼樣的流程或者策略：實際的J2EE項目中，RUP的應用呈逐年上升的趨勢，不過也並非所有這些採用了RUP的項目也是完完全全RUP式的。我們可以考慮一種綜合上面三種流程的優點的方式，根據具體的項目量體裁衣。需要對這幾種的優點來一個總結：瀑布式由於比較成熟，通常很好的強調了先需求後設計再編碼的重要性，也比較適合大公司先預算後執行的方式；極限編程強調測試先行和簡單是美，這樣有利於及早發現問題以及更好的應對變化；RUP強調的集中化的分析和設計也有其不可替代的優越性。要做出一個結論性的答案並不容易，如果貴公司相對較大並且願意支付一定的管理成本來推一套成熟且完整的開發流程並在公司內部所有項目或者是大多數項目嚴格執行，我想RUP應該是首選；如果貴公司希望有更大的靈活性，可以考慮一些折衷的方案，根據具體的項目，從上面三種流程提取有價值的部分，來確定具體的流程。

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

• 1.瀑布模型

  瀑布模型的特點是：

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

  優點：

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

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

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

  缺點：

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

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

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

  使用場合：

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

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

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

  

4. 迭代模型各個階段所佔比例

學習《軟體工程》，考生不僅需要掌握至少一門程序設計語言，還需要對數據結構、資料庫、操作系統等課程有一定的了解，可以說綜合性很強。
學習《軟體工程》必備書籍：
1．教材，《軟體工程》（黑皮），北京大學出版，2002年，王立福等
2．輔導，《計算機上機實驗考試應試指導》（藍皮），北京大學出版，2003年，孫家肅

《軟體工程》筆試分為理論部分和設計部分，比例大致相當，在下面的復習大綱中將隨即提到，不再細分。另外，實驗部分也會在文中提及，希望讀者注意。

第一章 軟體工程概論

1． 軟體工程的目的：
倡導以工程的原理、原則和方法進行軟體開發，以解決當時出現的軟體危機。

2． 軟體危機：
在計算機軟體開發和維護過程中所遇到的一系列問題。

3． 軟體及組成：
計算機系統中的程序和文檔稱為軟體，程序是計算機任務的處理對象和處理規則的描述，文檔是為了理解程序所需的闡述性資料。

4． 軟體工程定義：
軟體工程是一類求解軟體的工程，它應用計算機科學、數學及管理科學等原理，借鑒傳統工程的原則、方法，創建軟體以達到提高質量、降低成本的目的。其中，計算機科學、數學用於構造模型與演算法，工程科學用於制定規范、設計范型、評估成本及確定權衡，管理科學用於計劃、資源、質量、成本等管理。軟體工程是一門指導計算機軟體開發和維護的工程學科。

5． 軟體工程框架及其內容：
目標、活動和原則。軟體工程的目標為，生產具有正確性、可用性以及開銷合宜的產品。軟體工程活動定義為，生產一個最終滿足需求且達到工程目標的軟體產品所需要的步驟，主要包括需求、設計、實現、確認以及支持等活動。軟體工程設計原則為，選取適宜的開發模型，採用合適的設計方法，提供高質量的工程支持，重視開發過程的管理。（參考教材教材第2頁圖1.1，更有利於記憶）

6． 軟體工程研究的內容：
軟體開發模型、軟體開發方法、軟體過程、軟體工具、軟體開發環境、計算機輔助軟體工程（CASE）、軟體經濟學等。

7． 軟體開發方法學定義：
是一種已定義好的技術集和符號表示習慣，來組織軟體開發的過程，一般表示為一系列步驟，包括結構化方法、面向對象方法、Jackson方法等等。

第二章 軟體開發模型

1． 軟體開發模型定義：
是軟體開發全部過程、活動和任務的結構框架。

2． 瀑布模型內容及特點：
瀑布模型將軟體生存周期的各項活動規定為依固定順序連接的軟干階段工作，是一種線性模型。各階段活動為，提出系統需求、提出軟體需求、需求分析、設計、編碼、測試和運行。每個開發階段具有以下特徵，從上一階段接受本階段工作的對象作為輸入，對上述輸入實施本階段的活動，給出本階段的工作成果作為輸出傳入下一階段，對本階段工作進行評審，若本階段工作得到確認，則繼續下階段工作，否則返回前一階段甚至更前階段。瀑布模型最為突出的缺點是該模型缺乏靈活性。

3． 演化模型內容及特點：
演化模型主要針對事先不能完整定義需求的軟體開發，其開發過程一般是首先開發核心系統，當核心系統投入運行後，軟體開發人員根據用戶的反饋，實施開發的迭代過程，每一迭代過程均由需求、設計、編碼、測試、集成等階段組成，直到軟體開發結束。演化模型在一定程度上減少了軟體開發活動的盲目性。

4． 螺旋模型內容及特點：
它是在瀑布模型和演化模型的基礎上，加入兩者所忽略的風險分析所建立的一種軟體開發模型。沿螺旋模型順時針方向，依次表達了四個方面的活動，制定計劃、風險分析、實施工程、客戶評估。

5． 噴泉模型內容及特點：
它體現了軟體創建所固有的迭代和無間隙特徵，噴泉模型主要用於支持面向對象開發過程。

6． 增量模型內容：
在設計了軟體系統整體體系結構之後，首先完整的開發系統的一個初始子集，繼之，根據這一子集，建造一個更加精細的版本，如此不斷的進行系統的增量開發。

7． 瀑布模型、演化模型、螺旋模型之間的聯系：相同點是這三個模型都分為多個階段，而瀑布模型一次完成軟體，演化模型分為多次完成，每次迭代完成軟體的一個部分，螺旋模型也分為多次完成，每次完成軟體的一個新原型，並考慮風險分析。

8． 演化模型和增量模型之間的區別
演化模型首先開發核心系統，每次迭代為系統增加一個子集，整個系統是增量開發和增量提交，增量模型首先完整的開發系統的一個初始子集，然後不斷的建造更精細的版本。

教材可以在報名點購買（一般是正版，但價格較高，所以不建議在哪兒買），當地較大圖書市場肯定也有賣的，在這買較便宜，但是盜版的比較多，可以自己選質量較好的，價格可以還價，一般至少在7折，最便宜的可以到5折。

自考指定教材查詢：

歷年試卷：提示：在搜索裡面打軟體工程就行

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

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

6. 為什麼要使用軟體開發模型

軟體開發模型能清晰、直觀地表達軟體開發全過程，明確規定了要完成的主要活動和任務，用來作為軟體項目工作的基礎。對於不同的軟體系統，可以採用不同的開發方法、使用不同的程序設計語言以及各種不同技能的人員參與工作、運用不同的管理方法和手段等，以及允許採用不同的軟體工具和不同的軟體工程環境。

(6)軟體工程開發模型迭代擴展閱讀

軟體開發模型基本目標

1、開發盡可能多的軟體產品，滿足社會對軟體全方位、不同應用領域的應用需求，是軟體工程的首要目標。

2、提高軟體的生產效率。由於軟體產品的特殊性使得如何提高軟體產品的生產效率成了迫切需要解決的難題。為此，人們從各個方面研究、探討軟體產品生產的內在規律，包括生產過程的管理、組織形式、開發工具、程序設計方法等，試圖找出比較滿意的求解方案。

3、滿足應用的功能需要。這里包括幾層意思：產品功能強、性能好、按期交付使用、易於用戶操作和維護。

4、降低軟體開發成本，包括降低軟體設計成本和軟體維護成本，而軟體維護成本比開發成本要大得多。因此，提高軟體可維護性是降低軟體開發成本的有效途徑。

7. 軟體開發模型有幾種

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

8. 開發過程中據說的迭代是什麼意思

迭代是重復反饋過程的活動，其目的通常是為了逼近所需目標或結果。每一次對過程的重復稱為一次「迭代」，而每一次迭代得到的結果會作為下一次迭代的初始值。

重復執行一系列運算步驟，從前面的量依次求出後面的量的過程。此過程的每一次結果，都是由對前一次所得結果施行相同的運算步驟得到的。例如利用迭代法*求某一數學問題的解。

對計算機特定程序中需要反復執行的子程序*(一組指令)，進行一次重復，即重復執行程序中的循環，直到滿足某條件為止，亦稱為迭代。

(8)軟體工程開發模型迭代擴展閱讀

相關概念

函數

在數學中，迭代函數是在分形和動力系統中深入研究的對象。迭代函數是重復的與自身復合的函數，這個過程叫做迭代。

模型

迭代模型是RUP（Rational Unified Process，統一軟體開發過程，統一軟體過程）推薦的周期模型。

演算法

迭代演算法是用計算機解決問題的一種基本方法。它利用計算機運算速度快、適合做重復性操作的特點，讓計算機對一組指令（或一定步驟）進行重復執行，在每次執行這組指令（或這些步驟）時，都從變數的原值推出它的一個新值。

方法

迭代的方式就有所不同，假如這個產品要求6個月交貨，我在第一個月就會拿出一個產品來，當然，這個產品會很不完善，會有很多功能還沒有添加進去，bug很多，還不穩定，但客戶看了以後，會提出更詳細的修改意見。

這樣，你就知道自己距離客戶的需求有多遠，我回家以後，再花一個月，在上個月所作的需求分析、框架設計、代碼、測試等等的基礎上，進一步改進，又拿出一個更完善的產品來，給客戶看，讓他們提意見。

就這樣，我的產品在功能上、質量上都能夠逐漸逼近客戶的要求，不會出現我花了大量心血後，直到最後發布之時才發現根本不是客戶要的東西的情況。

優勢

這樣的方法很不錯，但他也有自己的缺陷，那就是周期長、成本很高。在應付大項目、高風險項目——就比如是太空梭的控制系統時，迭代的成本比項目失敗的風險成本低得多，用這種方式明顯有優勢。

如果你是給自己的單位開發一個小MIS，自己也比較清楚需求，工期上也不過花上個把月的時間，用迭代就有點殺雞用了牛刀，那還是瀑布模型更管用，即使是做得不對，頂多再花一個月重來，沒什麼了不起。

9. 軟體工程三種演化模型的相同點和不同點

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

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

螺旋模型：
它是在瀑布模型和演化模型的基礎上，加入兩者所忽略的風險分析所建立的一種軟體開發模型。沿螺旋模型順時針方向，依次表達了四個方面的活動，制定計劃、風險分析、實施工程、客戶評估。

噴泉模型
它體現了軟體創建所固有的迭代和無間隙特徵，噴泉模型主要用於支持面向對象開發過程。
增量模型內容：
在設計了軟體系統整體體系結構之後，首先完整的開發系統的一個初始子集，繼之，根據這一子集，建造一個更加精細的版本，如此不斷的進行系統的增量開發。

瀑布模型、演化模型、螺旋模型之間的聯系：相同點是這三個模型都分為多個階段，而瀑布模型一次完成軟體，演化模型分為多次完成，每次迭代完成軟體的一個部分，螺旋模型也分為多次完成，每次完成軟體的一個新原型，並考慮風險分析。

演化模型和增量模型之間的區別
演化模型首先開發核心系統，每次迭代為系統增加一個子集，整個系統是增量開發和增量提交，增量模型首先完整的開發系統的一個初始子集，然後不斷的建造更精細的版本。