4.2.2　統(tǒng)一過程的動態(tài)結構：迭代開發(fā)

Rational統(tǒng)一過程的動態(tài)結構，是通過對迭代式軟件開發(fā)過程的周期、階段、迭代過程以及里程碑等的描述來表示的。在統(tǒng)一過程二維結構的橫坐標軸上，顯示了統(tǒng)一過程的生命周期，將軟件開發(fā)的各個階段和迭代周期在這個水平時間軸表達出來，反映了軟件開發(fā)過程沿時間方向的動態(tài)組織結構。

在最初的軟件開發(fā)方式—順序開發(fā)過程，即瀑布模型中，將系統(tǒng)需求分析、設計、實現(xiàn)（包括編碼和測試）和集成順序地執(zhí)行，并在每一個階段產生相關的產物。項目組織順序執(zhí)行每個工作流，并且每個工作流只能被執(zhí)行一次，這就是大家熟悉的瀑布模型的生命周期，這樣做的結果是只有到末期編碼完成并開始測試時，在需求分析、設計和實現(xiàn)階段所遺留的隱藏問題才會大量出現(xiàn)，項目可能要進入一個漫長的錯誤修正周期中。即使在后期的集成中，也會不可避免地會發(fā)生一些很重大的錯誤。

一種更靈活，風險更小的方法就是通過多次不同的開發(fā)工作流，逐步確定一部分需求分析和風險，在設計、實現(xiàn)并確認這一部分后，再去做下一部分的需求分析、設計、實現(xiàn)和確認工作，以此方式反復進行下去，直至整個項目的完成。這樣能夠在逐步集成中更好地理解需求，構造一個健壯的體系結構，并最終交付一系列逐步完成的版本。這叫作一個迭代生命周期。在工作流中的每一次順序的通過被稱為一次迭代過程。軟件生命周期是迭代的連續(xù)，通過它，軟件是增量的開發(fā)。一次迭代包括了生成一個可執(zhí)行版本的開發(fā)活動，還有使用這個版本所必需的其他輔助成分，如版本描述、用戶文檔等。因此一個開發(fā)迭代在某種意義上是在所有工作流中一次完整的過程，這些工作流包括：需求分析工作流、設計工作流、實現(xiàn)和測試工作流、集成工作流。可以看出，迭代過程的一個開發(fā)周期本身就像一個小型的瀑布模型。

當從一個迭代過程進入到另外一個迭代過程時，需要一種方法對整個項目的進展情況進行評估，以確保大家是在朝著最終產品的方向努力。我們使用里程碑（Milestone）的方式及時地根據(jù)明確的準則決定是繼續(xù)、取消還是改變迭代過程。為了對迭代的特定短期目標進行分割并組織迭代開發(fā)秩序，我們將迭代過程劃分為4個連續(xù)的階段。分別為：

• 初始（Inception）階段
• 細化（Elaboration）階段
• 構造（Construction）階段
• 提交（Transition）階段

在每一個階段完成之后，都會形成一個良好定義的里程碑，即必須做出某些關鍵決策的時間點，因此在每一個階段結束后，必須要達到關鍵的目標。每個階段均有明確的目標。下面詳細介紹各個階段的目標以及重要里程碑的評價準則。

1．初始（Inception）階段

初始階段的目標是為系統(tǒng)建立商業(yè)案例和確定項目的邊界。

為了達到該目標必須識別所有與系統(tǒng)交互的外部實體，在較高層次上定義交互的特性。它包括識別所有用例和描述一些重要的用例。商業(yè)案例包括驗收規(guī)范、風險評估、所需資源估計、體現(xiàn)主要里程碑日期的階段計劃。

本階段具有非常重要的意義，在這個階段中，關注的是整個項目開發(fā)過程中的業(yè)務和需求方面的主要風險。對于建立在原有系統(tǒng)基礎上的開發(fā)項目來說，初始階段的時間可能很短。

2．細化（Elaboration）階段

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

細化階段是四個階段中最關鍵的階段。該階段結束時，決定了是否能將項目提交給構造和提交階段。對于大多數(shù)項目而言，這也相當于從變動的、輕松的、靈巧的、低風險的運作過渡到高成本、高風險并帶有較大慣性的運作過程。而過程必須能容納變化，細化階段的活動確保了結構、需求和計劃是足夠穩(wěn)定的，風險被充分減輕，所以可以為開發(fā)結果預先決定成本和日程安排。

在細化階段，可執(zhí)行的結構原型在一個或多個迭代過程中建立，依賴于項目的范圍、規(guī)模、風險和先進程度。工作量必須至少處理初始階段中識別的關鍵用例，典型的關鍵用例揭示了項目主要技術的風險。

3．構造（Construction）階段

在構造階段，所有剩余的構件和應用程序功能被開發(fā)并集成為產品，所有的功能被仔細地測試。

在構造階段，從某種意義上說，是重點在管理資源和控制運作來優(yōu)化成本、日程、質量的生產過程。許多規(guī)模大的項目足夠產生許多平行的增量構造過程，這些平行的活動可以極大地加速版本發(fā)布的有效性；同時也增加了資源管理和工作流同步的復雜性。健壯的體系結構和易于理解的計劃是高度關聯(lián)的。換而言之，體系結構上關鍵的質量決定了構造的容易程度，這也是在細化階段均衡的體系結構和計劃被一再強調的原因。

4．提交（Transition）階段

提交階段（也稱為交付階段）的目的是將軟件產品交付給用戶群體。

只要產品發(fā)布給最終用戶，問題常常就會出現(xiàn)：要求開發(fā)新版本，糾正問題或完成被延遲的問題。

當軟件產品的最基本底線成熟到足夠發(fā)布給最終用戶時，就進入了提交階段。一些典型需求的系統(tǒng)子集被開發(fā)到可用、可接收的質量級別，并且用戶文檔也可供使用，從而交付給用戶的所有部分均可以有正面的效果。這包括：

• 對照用戶的期望值，驗證新系統(tǒng)的“beta測試”。
• 與被替代的已有系統(tǒng)并軌。
• 功能性數(shù)據(jù)庫的轉換。
• 向市場、部署、銷售團隊交付產品。

構造階段關注于向用戶提交產品的活動。一般情況下，該階段包括若干重復的過程，有Beta版本、通用版本、bug修補版和增強版。相當大的工作量消耗在開發(fā)面向用戶的文檔，培訓用戶等方面。在初始產品使用時，支持用戶并處理用戶的反饋。用戶反饋主要限定在產品性能調整、配置、安裝和使用問題。本階段的目標是確保軟件產品可以提交給最終用戶。

在Rational統(tǒng)一過程的每個階段可以進一步分解為迭代過程。迭代過程決定了可執(zhí)行產品版本（內部和外部）的完整開發(fā)循環(huán)，是最終產品的一個子集，從一個迭代過程到另一個迭代過程遞增式增長形成最終的系統(tǒng)。

與傳統(tǒng)的瀑布式方法相比，迭代過程具有以下優(yōu)點：

• 減小了風險。
• 更容易對變更進行控制。
• 高度的重用性。
• 項目小組可以在開發(fā)中學習。
• 較佳的總體質量。