從瀑布型開(kāi)發(fā)到迭代型開(kāi)發(fā)的轉變(4)

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

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

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

　　上面所列出的第一個(gè)和最后一個(gè)標準是架構師最關(guān)心的;項目經(jīng)理主要關(guān)注于前兩個(gè)。

　　對于每一個(gè)關(guān)鍵的用例，識別最重要的場(chǎng)景并用他們創(chuàng )建可執行的系統架構。換句話(huà)說(shuō)就是設計、實(shí)現和 測試這些場(chǎng)景。

　　步驟 4 ：采用迭代式的和風(fēng)險驅動(dòng)的管理過(guò)程。

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

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

　　初始階段: 通過(guò)獲得對所有需求的高層次的理解和確立系統的范圍來(lái)建立對系統將要構建什么的良好理解。減少多數的業(yè)務(wù)風(fēng)險，為構建系統產(chǎn)生業(yè)務(wù)用例，并從所有項目決策人得到是否繼續項目的確認。

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

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

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

　　回頁(yè)首

　　應用這些步驟的多種方法

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

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