迭代模型

出自 MBA智库百科(https://wiki.mbalib.com/)

迭代模型（Iterative Model）

　　早在20世紀50年代末期，軟體領域中就出現了迭代模型。最早的迭代過程可能被描述為“分段模型（stagewise model）”，其背景是H.D.Benington領導的美國空軍SAGE項目。

　　迭代模型是RUP（Rational Unified Process，統一軟體開發過程，統一軟體過程)推薦的周期模型。在RUP中，迭代被定義為：迭代包括產生產品發佈（穩定、可執行的產品版本）的全部開發活動和要使用該發佈必需的所有其他外圍元素。所以，在某種程度上，開發迭代是一次完整地經過所有工作流程的過程：（至少包括）需求工作流程、分析設計工作流程、實施工作流程和測試工作流程。

　　實質上，它類似小型的瀑布式項目。RUP認為，所有的階段（需求及其它）都可以細分為迭代。每一次的迭代都會產生一個可以發佈的產品，這個產品是最終產品的一個子集。迭代的思想如下圖所示。

　　在現代過程方法XP（eXtreme Programming，極限編程）、RUP無一例外地都推薦、主張採用能顯著減少風險的迭代模型。美國國防部原本提倡瀑布過程和觀點，在發現那麼多採用了瀑布模型的失敗的項目之後，不但放棄了對它的要求，而且從1994年的報告開始，積極地鼓勵採用更加現代化的迭代模型來取代瀑布模型做法。同時，中國中科院也提倡選用迭代模型。

　　對眾多的開發模型和過程方法，及權威機構的看法，企業應選擇什麼樣的開發模型，應慎重對從以下幾方面進行考慮：

　　1、RUP雖然內容極其豐富，定義了選起、精化、構建、產品化4個階段和業務建模、需求、分析設計、實現、測試、部署等9個工種，提供了一大堆的文檔模板，但極易讓人誤解是重型的過程，實施推廣有一定難度。

　　2、再次，在質量管理方面：以實現系統架構、核心功能目標的迭代產品生的工作成果作為質量控制重點。每次迭代進行系統集成、系統測試，達到對軟體質量的持續驗證。每次系統測試，需要回歸測試前一次迭代遺留髮現的問題。每次迭代發佈的小版本組織客戶（包括內部客戶、外部客戶）進行評價，通過演示操作等方式，評價該次迭代是否達到預定的目標，並以此為依據來制定下一次迭代的目標。

　　3、最後，在其他方面：每次迭代成果須進行配置管理，版本控制很重要。在整個迭代過程中風險無處不在，建議每周作一次風險跟蹤。同時通過重點關註進度、工作量、滿意度、缺陷等數據收集，關註每次迭代情況。

　　總之，選擇一個合適的生命周期模型，並應用正確的方法，對於任何軟體項目的成功是至關重要。企業在選擇開發模型應從項目時間要求、需求明確程度、風險狀況等選擇合適的生命周期模型。

　　1、在項目開發早期需求可能有所變化。

　　2、分析設計人員對應用領域很熟悉。

　　3、高風險項目。

　　4、用戶可不同程度地參與整個項目的開發過程。

　　5、使用面向對象的語言或統一建模語言（Unified Modeling Language，UML）。

　　6、使用CASE（Computer Aided Software Engineering，電腦輔助軟體工程）工具，如Rose（Rose是非常受歡迎的物件軟體開發工具。）。

　　7、具有高素質的項目管理者和軟體研發團隊。

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

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

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

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

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

　　不同的軟體過程模型對軟體開發過程有不同的理解和認識，支持不同的軟體項目和開發組織。下表對比和分析了各個軟體過程模型的特點及其適用的軟體項目類型。

　　各種軟體過程模型的特點