從瀑布型開發到迭代型開發的轉變(4)

　　功能是應用的核心，或者它使用的關鍵的接口。系統的關鍵功能應該能夠決定系統的體系架構。通常的情況下架構師通過分析很多因素來識別最重要的用例：冗余管理策略、資源爭奪風險、性能風險和數據安全策略等等。例如，在一個 POS 系統中，檢查(Check Out)和支付(Pay)是關鍵的用例，因為它驗證了信用卡確認系統的接口 — 并且它從性能和負載方面也是重要的。

　　選擇描述了 必須被交付功能的用例 。交付不包含關鍵功能的應用系統是沒有意義的。例如，一個訂單輸入系統如果不允許用戶輸入訂單將是不可接受的。通常，領域和問題專家能夠從用戶的角度理解被需要的關鍵功能(主要的行為、峰值數據處理、關鍵控制事務等等)，并且他們可以幫助定義關鍵的用例。

　　選擇描述了系統體系架構方面的功能并且沒有被其他關鍵用例所包含的用例。為了確保你的團隊能夠將注意力放在所有主要的技術風險上，他們必須理解系統的每一個區域。甚至如果一定的架構領域沒有出現在高風險中，它也許是隱藏了技術上的難度，這種技術上的難度僅僅能夠通過設計、實現和測試架構領域的一些功能才能夠被暴露出來。

　　上面所列出的第一個和最后一個標準是架構師最關心的;項目經理主要關注于前兩個。

　　對于每一個關鍵的用例，識別最重要的場景并用他們創建可執行的系統架構。換句話說就是設計、實現和 測試這些場景。

　　步驟 4 ：采用迭代式的和風險驅動的管理過程。

　　如果你將要遵循上面所描述的步驟 2 和步驟 3 ，那么你將會非常的接近“理想”迭代開發的模型。那么，你接下來的步驟應該是融合步驟 2 和步驟 3 ，并添加支持風險驅動和迭代開發的管理生命周期。這就是在 RUP 中被描述的迭代開式的生命周期。

　　RUP 對迭代開發提供了一個結構化的方法，它將一個項目劃分成為四個階段：初始階段、細化階段、構建階段和轉換階段。每一個階段包含了一個或者更多的迭代，每個迭代都關注于產生必要的技術上的可交付物以實現階段的業務目標。團隊經歷的迭代次數與需要實現階段的目標的數量是一樣的，而不是更多。如果在團隊計劃的迭代次數內他們沒有成功的實現這些目標，他們必須為那個階段添加額外的迭代 — 并且推遲項目。為了避免這種事情發生，你一定要嚴格的將你的精力集中在每個階段你需要實現的業務目標上。例如，在初始階段將精力過于集中在需求上將會成生相反的效果。下面是典型的階段目標的簡要描述。

　　初始階段: 通過獲得對所有需求的高層次的理解和確立系統的范圍來建立對系統將要構建什么的良好理解。減少多數的業務風險，為構建系統產生業務用例，并從所有項目決策人得到是否繼續項目的確認。

　　細化階段: 關心多數最具技術難度的任務：設計、實現、測試和基線化一個可執行的系統架構，包括子系統、他們的接口、關鍵組件和架構上的機制(例如，如何處理進程間通訊或者持久性問題)。通過實現和驗證實際的代碼，處理主要的技術任務，比如資源爭奪風險、性能風險和數據安全風險。

　　構建階段: 當你從一個可執行的系統架構遷移到系統的第一個可操作的版本時，需要完成大半的實現工作。部署數個內部和 alpha 版本以確保系統是可用的并且能夠滿足用戶的需要。通過部署一個完全功能的系統 beta 版本來結束這個階段，包括安裝、支持文檔和培訓材料;然而，要記住功能、性能和系統總的質量將很可能需要調整。

　　轉換階段: 確保軟件能夠滿足軟件用戶的需要。這個包括在系統發布的準備中測試產品，并且基于用戶的反饋對系統進行小的調整。在軟件開發周期的這個點上，用戶反饋應該主要的關注在微調產品和配置、安裝以及可用性的問題上;所有主要的結構問題已經在項目周期的早期被解決了。 1

　　回頁首

　　應用這些步驟的多種方法

　　在本文中，我們已經描述了你如何能夠使用四個步驟逐步的從瀑布型的開發方法轉換到增量的迭代開發方法。每一個步驟都以最小的中斷為你的開發工作添加了切實的價值。一些團隊每次不止使用一個步驟;其他的團隊可能在一個步驟上運作了幾個項目，然后才執行下一個步驟。然而，你應該選擇使用這種明智的實施方法，因為它能夠幫助你在開發組織中減少由于過程變化所帶來的風險。

原文轉自：http://www.ibm.com/developerworks/cn/rational/r-iterative/