基本概念

迭代開發(iterative development)是UP和大多數其他現代方法中的關鍵實踐。在這種生命周期方法中，開發被組織成一系列固定的短期(如三個星期)小項目，成為迭代(iteration)；每次迭代都產生經過測試、集成并可執行的局部系統。每次迭代都具有各自的需求分析、設計、實現和測試活動。

在迭代的過程中一步步增量式地發展完整系統，這種方法也成為迭代和增量式開發(iterative and incremental development)。

迭代的輸出不是實驗性的或將丟棄的原型，迭代開發也不是構造原型。與此相反，其輸出式最終的產品子集。

早期反饋具有極高的價值。“不錯……但是……”這種早期反饋并不是失敗的標志，與此相反，早期頻繁地在“不錯……但是……”中循環，正是改進軟件和發現什么對涉眾有真正價值的使用方式。

迭代除了可以明確需求外，還將有助于及早地解決和驗證具有風險的、關鍵的設計決策。

大部分迭代方式建議迭代時間在2~6周之間。短時迭代為上。

迭代的一個關鍵思想是時間定量，或時長固定。即必須嚴格依照時間表來集成、測試和穩定局部系統——拖延實踐則違約。如果覺得難以滿足期限要求，則應將本次迭代任務進行拆解，抽出一部分放到下一次迭代中完成，而不是推遲完成的時間。

不要讓瀑布思維侵蝕迭代或UP項目。

進行迭代開發的步驟：

1. 在第一次迭代之前，召開第一個時間定量的需求工作會議，進行高階需求分析，如僅僅確定用例和特性的名稱，以及關鍵的非功能性需求。在高階需求列表中選取10%具有架構意義、高業務價值的需求進行功能和非功能性需求的詳細分析；
2. 在第一次迭代錢，召開迭代計劃會議，從做好初步詳細分析的用例中選擇本次迭代的任務目標；
3. 在三到四周內完成第一次迭代，并嚴格遵守時間；
4. 在第一次迭代即將結束時，召開第二次需求工作會，對上一次會議的所有材料進行復查和凈化。然后選擇具有重要架構意義和高業務價值的另外10%到15%的用例，用一到兩天對其進行詳細分析；
5. 于第一次迭代結束最后一天舉行下一次迭代的迭代計劃會議；
6. 以相同步驟進行第二次迭代；
7. 反復進行四次迭代和五次需求工作會，這樣在第四次迭代結束時，可能已經詳細記錄了約80%~90%的需求，但只實現了系統的10%；
8. 大約推進了整個項目的20%，這是細化階段。此時根據分析以及早期反饋、早期編程及測試，已經可以獲取系統的概貌和各種風險，可以把握住開發并能估計出需要多長時間來結束；
9. 此后，一般不需要再召開工作會，需求已經穩定了，接下來時一些列為期三周的迭代。

UP提倡風險驅動(risk-driven)與客戶驅動(client-driven)相結合的迭代計劃。這意味著早期的迭代目標要能夠識別和降低最高風險，并且能構造客戶最關心的可視化特性。

敏捷宣言：個體和迭代，超越過程和工具；工作的軟件，超越完整的文檔；客戶協作，超越合同談判；響應變更，超越履行計劃。

UP項目將其工作和迭代組織為四個主要階段：初始，細化，構造，移交。