迭代過程一般分為四個階段：初始、細化、構造和移交，簡稱為I,E,C和T。每個階段以一個重要的里程碑(milestone)結束。?

初始(Inception)階段

確定最終產品的構想及其業務用例、并定義項目范圍

初始階段以生命周期目標(LCO)里程碑為結束點

細化(Elaboration)階段

計劃出必須完成的活動和需要的資源；詳細說明產品特性并設計架構

細化階段以生命周期構架(LCA)里程碑為結束點?

構造(Construction)階段

構造整個產品，逐步完善視圖、構架和計劃，直到產品(完整的構想)已完全準備好交付給用戶。

構造階段以最初運作能力(IOC)里程碑為結束點。

移交(Transition)階段

移交產品給用戶，包括制造、交付、培訓、支持及維護產品，直至用戶滿意。

移交階段以產品發布版本里程碑為結束點，這也是整個周期的結束點。

?

I,E,C,T這四個階段構成了開發周期，當周期結束時產生一代軟件產品。

軟件產品重復IECT這個過程，從而發展成為下一代產品。

周期與周期之間是可以存在時間重疊的。一個周期的初始與細化階段與上一個周期的移交階段可能是同時進行的。

從一個迭代過程到另一個迭代過程，從一個階段到另一個階段，重點關注的活動是不同的。初始階段，焦點主要放在理解所有的需求并決定開發工作量的范圍上。 細化階段，焦點放在需求上。一些軟件設計和實施的目標是開發構架原型，用來緩解特定技術風險并學習運用特定的工具和技術。此構架原型將作為下一階段的基線。構架階段，焦點放在產品的設計與實現上。這時，可以在最初的構架原型基礎上生產出第一個可以運行的產品。 移交階段，焦點是確保系統保持預期的質量水平；修復缺陷、培訓用戶、調整特性、增加遺漏掉的元素。至此，交付最終產品。

?

初始階段：

主要任務：

令所有的項目相關人員對生命周期目標達成一致意見。

主要目標：

確定項目的軟件范圍和邊界條件，包括一個可操作的概念、可接受的準則和什么是產品目標、以及什么不是產品目標的詳盡描述

識別系統的關鍵用例——即主要行為情景

展示或者示范至少一個針對主要情景的候選構架

估計整個項目需要的費用和時間表，并對下一階段給出評估

評估風險(不確定性的來源)

主要活動：

系統化地明確表述項目的范圍——即捕獲項目的語境、需求及限制。

計劃并準備業務用例，評價風險管理、人員配備、項目計劃，權衡成本、進度和利潤。

合成一個候選構架，評價有關設計因素，評估制作/買進/重用的對策，以估算成本、進度和需要的資源。

成果和制品 ：

一個構想文檔——即關于項目核心需求、關鍵特性和主要限制的構想

一個關于用例模型的調查，包括所有在此階段可以確定的用例和參與者

初期的項目術語

一個初始的業務用例，包括 業務環境 、關于是否成功的評價標準(項目收入、市場認識等) 、經濟預測

一個早期的風險評估

一個可以顯示階段和迭代的項目計劃

可能還會產生以下制品：

完成10%-20%的用例模型

一個比術語表更詳細的領域模型

一個業務模型

一個初步的開發案例描述，用于詳細說明將用到的過程

一個或幾個原型

生命周期目標里程碑：

生命周期目標里程碑評價初始階段的準則如下：

是否定義了項目范圍，估計了成本和制定了進度安排。

評估用例對需求的理解是否正確

評估成本、進度安排、優先權、風險和開發過程的可信度

實際成本與計劃成本的對比

?

細化階段：

主要任務：

分析問題領域、建立合理的構架基礎、確定項目計劃、評價項目最有可能出現的風險因素。

主要目標：

以實際所能達到的最快速度定義、確認構架，并將其基線化

設置構想的基線

為構造階段的高可信度計劃設定基線

考慮構想的基線的合理性，即可以在合理的時間內以合理的費用來完成

主要活動：

細化構想，完成和明確大部分的關鍵用例，這些用例將驅動做出最終構架和決定計劃。

細化過程、基礎設施和開發環境，過程、工具和自動支持也都各就各位。

細化構架并選擇組件。

成果和制品：

用例模型至少完成80%，包括定義了在用例模型調查中識別出的所有用例、參與者和大部分用例描述。

補充需求分析，包括非功能性需求

一個軟件構架描述

一個可執行的構架原型

一個修改過的風險清單和業務用例

一個整個項目的開發計劃，計劃中顯示了迭代過程和每個迭代過程的評價準則。

一個已更新的開發案例，其中詳細描述了將要用到的過程。

一個初步的用戶手冊(可選的)。

生命周期架構里程碑：

生命周期構架里程碑檢驗細化的系統目標和范圍、構架的選擇以及主要風險的解決方案。

評價準則：

產品構想是否穩定？ 構架是否穩定？ 可執行的演示中，主要風險因素是否已經確實處理并解決？ 構造階段計劃是否足夠詳細精確？估計是否建立在可信的基礎上？ 后繼開發人員是否會認可當前的構想？ 實際的資源消耗相對于計劃消耗來說是否可以接受

?

構造階段：

主要任務 ：

所有保留下來的構件和應用程序特征將被開發并集成以形成產品，而后所有的特征將被徹底測試。

主要目標：

優化資源和避免不必要的浪費和返工，降低開發成本。

以實際最快的速度提高產品質量

以實際最快的速度生產一個可用的版本(beta)?

主要活動 ：

資源管理、資源控制和過程優化

完成構件開發并根據已定義的評價準則進行測試

針對根據構想制定的接受準則對發布的產品進行評估

成果和制品 ：

在適當的平臺上集成的軟件產品

用戶手冊

對當前版本的描述

最初運作能力里程碑：

最初運作能力里程碑要明確軟件、場地、用戶是否都準備好正常運行而沒有將項目暴露在高風險下，這個版本通常被稱為beta版本。

評價準則：

這個產品版本是否足夠成熟穩定，可在用戶群中實施？ 是否所有項目相關人員都準備好將產品向用戶群推廣？ 實際的資源消耗相對于計劃消耗是否可以被接受？

?

移交階段：

主要任務：

將軟件產品移交給用戶群，具體包括:

Beta測試，確認系統與用戶的期望是否一致

平行操作項目，取代一流系統

轉換運行的數據庫

培訓用戶和維護人員

產品的首次展示

主要目標：

達到用戶自我可支持的程度

完成實施基線，該基線滿足構想的評價準則

以實際可能的最快速度和最高效益達到最終的產品基線

主要活動：

完成實施工作：結尾工作、商業包裝和生產、銷售展示以及訓練專業人員

調整活動，包括修復缺陷以及為了提高性能和可使用性而作的添加

根據產品構想的接受準則評估實施基線

產品發布里程碑：

產品發布里程碑判斷本周期目標是否達到，并決定是否要進入下一個新的開發周期。 有些情況下，這個里程碑會與下一個周期的初始階段的結束點同時發生。

評價準則： 用戶是否滿意？ 實際的資源消耗相對于計劃消耗是否可以被接受？

?

總結

以上是生活随笔為你收集整理的RUP之动态结构：迭代开发的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。