早在20世紀50年代末期，軟體領域中就出現了迭代模型。最早的迭代過程可能被描述為“分段模型（stagewise model）”。迭代模型是RUP推薦的週期模型。被定義為：迭代包括產生產品釋出（穩定、可執行的產品版本）的全部開發活動和要使用該釋出必需的所有其他外圍元素。在某種程度上，開發迭代是一次完整地經過所有工作流程的過程：需求分析、設計、實施和測試工作流程。實質上，它類似小型的瀑布式專案。RUP認為，所有的階段都可以細分為迭代。每一次的迭代都會產生一個可以釋出的產品，這個產品是最終產品的一個子集。

在現代過程方法XP（eXtreme Programming，極限程式設計）、RUP無一例外地都推薦、主張採用能顯著減少風險的迭代模型。美國國防部從1994年的報告開始，積極地鼓勵採用更加現代化的迭代模型來取代瀑布模型做法。同時，中國中科院也提倡選用迭代模型。

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

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

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

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

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

其實，迭代模型專案就是數個小而快的瀑布式專案組成的。因為，每一次開發迭代都是一次完整地經過所有工作流程的過程：需求、分析設計、實施和測試工作流程。每一次的迭代都會產生一個可以釋出的產品，這個產品是最終產品的一個子集。迭代模型沿著螺線進行若干次迭代，圖中的四個象限代表了四個活動：制定計劃、風險分析、實施工程、客戶評估。使用迭代模型進行軟體開發，專案活動包含以下幾個階段：

1。 初始階段

為系統建立商業案例並確定專案的邊界。

2。 細化階段

細化階段的目標是分析問題領域，建立健全的體系結構基礎，編制專案計劃，淘汰專案中最高風險的元素。

3。 構造階段

在構建階段，所有剩餘的構件和應用程式功能被開發並整合為產品，所有的功能被詳細測試。

4。 交付階段

交付階段的重點是確保軟體對終端使用者是可用的。交付階段可以跨越幾次迭代，包括為釋出做準備的產品測試，基於使用者反饋的少量的調整。

迭代模型由風險驅動，強調可選方案和約束條件從而支援軟體的重用，有助於將軟體質量作為特殊目標融入產品開發之中。因此，迭代模型的風險管理成本較高，在風險分析，進度管理方面，對專案組成員的要求也非常高。選擇迭代模型的專案，通常屬於高風險專案，且需求不確定，使用者能在整個開發過程中不同程度地參與。