給你一個標準的定義：
在RUP中，迭代被定義為：迭代包括產生產品發布（穩定、可執行的產品版本）的全部開發活動和要使用該發布必需的所有其他外圍元素。
這個定義太學究氣，半天看不明白。這樣解釋可能更容易理解：
我們開發一個產品，如果不太復雜，會采用瀑布模型，簡單的說就是先需求定義，然后構建框架，然后寫代碼，然后測試，最后發布一個產品。
這樣，幾個月過去了，直到最后一天發布時，大家才能見到一個產品。
這樣的方式有明顯的缺點，假如我們對用戶的需求判斷的不是很準確時——這是很常見的問題，一點也不少見——你工作了幾個月甚至是幾年，當你把產品拿給客戶看時，客戶往往會大吃一驚，這就是我要的東西嗎？
迭代的方式就有所不同，假如這個產品要求6個月交貨，我在第一個月就會拿出一個產品來，當然，這個產品會很不完善，會有很多功能還沒有添加進去，bug很多，還不穩定，但客戶看了以后，會提出更詳細的修改意見，這樣，你就知道自己距離客戶的需求有多遠，我回家以后，再花一個月，在上個月所作的需求分析、框架設計、代碼、測試等等的基礎上，進一步改進，又拿出一個更完善的產品來，給客戶看，讓他們提意見。
就這樣，我的產品在功能上、質量上都能夠逐漸逼近客戶的要求，不會出現我花了大量心血后，直到最后發布之時才發現根本不是客戶要的東西。
這樣的方法很不錯，但他也有自己的缺陷，那就是周期長、成本很高。在應付大項目、高風險項目——就比如是航天飛機的控制系統時，迭代的成本比項目失敗的風險成本低得多，用這種方式明顯有優勢。
如果你是給自己的單位開發一個小MIS，自己也比較清楚需求，工期上也不過花上個把月的時間，用迭代就有點殺雞用了牛刀，那還是瀑布模型更管用，即使是做得不對，頂多再花一個月重來，沒什么了不起
賣藝網