第八章細化階段的迭代1－－基礎目標定義細化階段的第一個迭代。為本部分的后續章節做鋪墊。描述初始和細化階段的關鍵內容。迭代1的需求和重點：OOA/D的技術核心案例一：NextGenPOSNextGenPOS應用在第一個迭代要處理的需求：實現處理銷售用例中基本和關鍵的場景：輸入商品項目并收取現金。實現用于支持迭代初始化需要的啟動用例。不處理任何特殊和復雜的部分，僅僅針對場景的簡單理想路徑，并對此進行設計和實現。不與外部服務進行協作，例如，稅金計算器或產品數據庫。不應用復雜的定價規則。迭代1的需求和重點：OOA/D的技術核心案例二：Monopoly游戲Monopoly游戲應用在第一個迭代要處理的需求：實現玩Monopoly游戲用例的基本和關鍵場景：游戲者圍繞棋盤四周的方格移動。實現基于支持迭代初始化需求的啟動用例。支持2-8個游戲者。游戲通過一系列回合進行。每個回合中，每個游戲者輪得一次機會。在每一次輪次中，游戲者根據所拋擲的兩個六面骰子的點數總和，在圍繞棋盤的方格上，按順時針方向將棋子移動相應的格數。游戲只能進行20回合。拋擲骰子后，顯示游戲者的姓名和擲骰子的結果。當游戲者移動并占據一個方格后，顯示游戲者名字和所占方格的名稱。在迭代1中，不考慮金錢、輸贏、買進或支付租金以及任何種類的特殊方格。每個方格都有相應的名稱。游戲開始時，每個游戲者的棋子都在名為“Go”的方格上。方格的名稱將一次為Go、方格1、方格2、……、方格39.除了游戲者的數量外，游戲以模擬的方式運行，不需要任何用戶輸入。迭代1在迭代開發中，我們并非一次就實現所有需求。迭代1的需求是所有需求或用例的子集。對需求子集開始具有產品品質的編程和測試，并且我們在完成所有需求分析之前開始這些開發，這與瀑布過程相反。迭代1在多個迭代里對同一用例進行增量式開發。注意，并不是在迭代1里要實現處理銷售用例中的所有需求。通常是在若干迭代內對同一用例的各種場景進行開發，并且漸進地擴展系統直到最終完成所有需要的功能性。簡短的用例可以在一次迭代中完成。過程：初始和細化案例研究的初始階段大概只持續了一周，所創建的制品應該是簡明和不完整的。初始階段是邁向細化階段的一小步。在該階段決定基本的可行性、風險和范圍，對項目是否值得進行更深入的調查進行決策。包括簡短的需求討論會。大多數參與者、目標和用例名稱。確定大多數具有影響和風險的質量需求。編寫設想和補充性規格說明的第一個版本。風險列表技術上的概念驗證原型和其他調查，用以解釋特殊需求的技術可行性。面向用戶界面的原型，用于確定對功能需求的設想。對購買/構建/復用構件的建議，在細化階段進行精化。對候選的高層架構和構件給出建議。第一次迭代的計劃。候選工具列表。細化細化是一般項目中最初的一系列迭代，其中包括：對核心、有風險的軟件架構進行編程和測試。發現并穩定需求的主體部分。規避主要風險。細化小組進行細致的調查、實現（編程和測試）核心架構、澄清大多數需求和應對高風險問題。細化階段通常由兩個或多個迭代組成，建議每次迭代的時間為2－6周。每次迭代都是時間定量的，這意味這其結束日期是固定的。細化細化不是設計階段，在該階段也不是要完成所有模型的開發。原型－－產生的代碼和設計是具有產品品質的最終系統的一部分。細化架構原型－－這一術語通常用來描述局部系統，不是指可廢棄的、實驗性的原型。在UP中，它表示最終系統的產品化子集。該術語更常見的名稱是可執行架構或架構基線。細化用一句話來概括細化：構建核心架構，解決高風險元素，定義大部分需求，以及預計總體進度和資源。實行短時間定量、風險驅動的迭代。及早開始編程。對架構的核心和風險部分進行適應性的設計、實現和測試。盡早、頻繁、實際地測試。基于來自測試、用戶、開發者的反饋進行調整。通過一系列討論會，詳細編寫大部分用例和其他需求，每個細化迭代舉行一次。在細化階會開始構建哪些制品領域模型領域概念的可視化，類似于領域實體的靜態信息模型。設計模型描述邏輯設計的一組圖，包括軟件類圖、對象交互圖、包圖等。軟件架構文檔學習輔助工具，概括關鍵架構問題及其在設計中的解決方案。該文檔是對重要設計思想及其在系統中動機的概要。數據模型包括數據庫方案，以及在對象和非對象表示之間映射的策略用例示意板，用戶界面模型描述用戶界面、導航路徑、可用性模型等。細化階段常見錯誤對于大部分項目，細化階段都比“幾個”月更長。只有一次迭代。在細化開始前就定義了大部分需求。沒有處理具有風險的元素和核心架構。沒有產生可執行架構；沒有進行產品代碼的編程。認為細化階段主要是需求或設計階段，為構造階段的實現進行準備。試圖在編程之前進行徹底和細致的設計。只有少量的反饋和調整；用戶沒有持續地參與評估和反饋。沒有盡早和實際的測試。在編程之前推測性地結束架構設計。認為細化階段是進行概念驗證編程的階段，而不是對產品化核心架構編程的階段。過程：計劃下一個迭代