簡介 本章將概括案例研究在迭代1的需求，然后簡要討論初始和細化階段的過程思想。為理解后續章節對本次迭代的討論，閱讀選擇需求很重要。
迭代1的需求和重點：OOA/D技術的核心
在這些案例中，細化階段打得迭代1強調的是基礎范圍和在構建對象系統中所使用的常見OOA/D技術。當然，構建軟件還需要其他許多技術，例如數據庫設計、可用性工程、UI設計等，但是本書主要關注OOA/D和UML應用，其他技術不在本書涵蓋范圍之內。
在迭代開發中，我們并非一次就實現所有需求
對迭代生命周期方法（例如UP、XP、Scrum等）的關鍵理解就是：我們對需求子集開始具有產品品質的編程和測試，并且我們在完成所有需求分析之前開始這些開發，這與瀑布過程相反。
在多個迭代里對同一用例進行增量式開發 注意，并不是在迭代1里要實現處理銷售用例中的所有需求。通常是在若干迭代內對同一用例的各種場景進行開發，并且逐漸地擴展系統直到最終完成所有需要的功能性（圖8-1）另一方面，簡短的用例可以在一次迭代中完成。
過程：初始和細化 在初始階段發生了什么
案例研究的初始階段大概只持續了一周。因為這不是項目的需求階段，所創建的制品應該是簡明和不完整的，該階段用時很短，并且只經過輕量級的調查。
初始階段是邁向細化階段的一小步。在該階段決定基本的可行性、風險和范圍，對項目是否值得進行更深入的調查進行決策。并不是所有適合于初始階段的活動都要涵蓋在其中，這一階段強調面向需求的制品。初始階段中可能的活動和制品包括：
- 簡短的需求討論會
- 大多數參與者、目標和用例名稱。
- 大多數以摘要形式編寫的用例。以詳述形式編寫10%~20%的用例，以加深對范圍和復雜性的理解
- 確定大多數具有影響和風險的質量需求。
- 編寫設想和補充性規格說明的第一個版本
- 風險列表
- 技術上的概念驗證原型和其他調查，用以揭示特殊需求的技術可行性
- 面向用戶界面的原型，用于確定對功能需求的設想
- 對購買/構建/復用構建的建議，在細化階段進行精化。
- 對候選的高層架構和構件給出建議。
- 第一次迭代的計劃
- 候選工具列表
細化之所在
細化階段是最初的一系列迭代，在這一階段，小組進行細致的調查、實現（編程和測試）核心架構、澄清大多數需求和應對高風險問題。在UP中，“風險”包含業務價值。因此，早期工作可能包括實現那些被認為重要的場景，而不是專門針對技術風險。
細化階段通常由兩個或多個迭代組成，建議每次迭代的時間為2~6周。
在這一階段，不是要創建可以丟棄的原型。與之相反，該階段產生的代碼和設計是具有產品品質的最終系統的一部分。在一些UP的描述中，會誤解"架構原型"(architectural
prototype)這一術語用來描述局部系統。該術語不是指可廢棄的、實驗性的原型，在UP中，它表示最終系統的產品化子集。該術語更常見名稱是可執行架構(executable architecture)或架構基線(architectural baseline)。 用一句話來概括細化：構建核心架構，解決高風險元素，定義大部分需求，以及預計總體進度和資源。
在細化階段可能出現的一些關鍵思想和最佳實踐包括：
- 實行短時間定量、風險驅動的迭代。
- 及早開始編程
- 對架構的核心和風險部分進行適應性的設計、實現和測試。
- 盡早、頻繁、實際地測試。
- 基于來自測試、用戶、開發者的反饋進行調整。
- 通過一系列討論會，詳細編寫大部分用例和其他需求，每個細化迭代舉行一次。
在細化階段會開始構建哪些制品 表8-1列出的是可能在細化階段開始構建的制品樣例，同時指明這些制品要解決的問題。
何時知道自己并沒有理解細化階段
- 對于大部分項目，細化階段都比“幾個”月更長。
- 只有一次迭代（除極少數易于理解的問題外）
- 在細化開始前就定義了大部分的需求
- 沒有處理具有風險的元素和核心架構。
- 沒有產生可執行架構，沒有進行產品代碼的編程。
- 認為細化階段主要是需求或設計階段，為構造階段的實現進行準備。
- 試圖在編程之前進行徹底和細致的設計
- 只有少量的反饋和調整；用戶沒有持續地參與評估和反饋。
- 沒有盡早和實際的測試
- 在編程之前推測性地結束架構設計
- 認為細化階段是進行概念驗證編程的階段，而不是對產品化核心架構編程的階段。
如果在項目中出現這些現象，則表明你對細化階段的理解是錯誤的，并且已經在UP之上強加了瀑布思想。
過程：計劃下一個迭代 通過風險、覆蓋范圍和關鍵程度組織需求和迭代。
- 風險既包括技術復雜性、也包括其他因素，例如工作量或可用性的不確定性。
- 覆蓋范圍意味著在早期迭代中至少要涉及系統的所有主要部分--或許是對大量構建進行“廣泛和膚淺”的實現。
- 關鍵程度是指客戶認為具有高業務價值的功能。
在迭代1之前完成等級劃分，但是在迭代2之前要重新劃分，依此類推，因為新需求和新理解會對等級排列產生影響。也就是說，迭代的計劃是可適應的，并不是項目開始之時必須固定下來的。