本文來自于 Rational Edge：這篇文章描述了一個迭代的、風險驅(qū)動的、以構架為中心的，以及面向質(zhì)量的方法開發(fā)的方法，這源自于IBM Rational 統(tǒng)一過程（Rational Unified Process，RUP)開發(fā)團隊的長期經(jīng)驗。它首先描述了這個工作產(chǎn)品的產(chǎn)生，然后闡述了一個在整個方法開發(fā)項目中逐步應用這個方法的路線圖。這個方法利用了軟件開發(fā)和RUP規(guī)程，能夠使用IBM Rational Method Composer (RMC)來執(zhí)行。 十多年以來，IBM Rational Unified Process?，或者RUP?，團隊一直采用“利用自己成果”的方法在開發(fā)方法框架，也就是說，運用RUP自己所提倡的規(guī)程、過程和技巧來進行軟件開發(fā)工作。然而，開發(fā)一個像RUP一樣的方法框架與開發(fā)一個軟件應用程序并不完全一樣。 1 這些年以來，RUP團隊對于方法開發(fā)的具體需求已經(jīng)適應了它自己的過程和技巧。 2 利用IBM Rational Method Composer 3 (RMC)的實用性，已經(jīng)有越來越多IBM內(nèi)部的團隊和顧客開始規(guī)定或者自定義方法。因此，對方法開發(fā)的指導的需求也日益增長。 這篇文章基于我在RUP團隊開發(fā)方法中的經(jīng)驗提出了一個方法開發(fā)的方法。這個方法通過一個路線圖呈現(xiàn)出來，這個路線圖可以指導您完成一個典型方法開發(fā)項目的整個生命周期。在這之后是方法與軟件開發(fā)主要不同與相同點的討論，還有方法開發(fā)項目過程中基本工作產(chǎn)品定義的介紹，我將從頭至尾地談到典型方法開發(fā)項目的每一個狀態(tài)（先啟、精化、構建，以及產(chǎn)品化）。 這篇文章介紹的方法開發(fā)的方法是迭代的和風險驅(qū)動的。我著重強調(diào)了每個迭代中以增量方式開發(fā)實際的方法，與簡單地產(chǎn)生項目相關文檔是對立的。這使得反饋和項目的計劃或者指導等靈活性更加便利。這種方法集中強調(diào)對現(xiàn)有資產(chǎn)的評估，以及在項目早期穩(wěn)定方法架構和任何高風險的方法元素，從而避免了可能導致項目失敗的問題的出現(xiàn)。它還通過早期介紹，以及對此方法進行頻繁的檢查和測試強調(diào)了質(zhì)量的重要性。 我已經(jīng)在腦子里用RMC對這個被提議的方法進行了定義，既確保了這個方法與工具術語上的一致性，又保證使用RMC可以使這個方法很容易地被執(zhí)行。無論如何，這種方法在RMC環(huán)境以外能夠非常廣泛地被利用。比如，您可以利用它編寫一本方法書籍。 這種方法支持臨時新方法的定義，還對現(xiàn)有方法有效自定義制定的支持，例如，將RUP延伸為面向服務的架構（SOA 的 RUP），或者將SOA的RUP延伸為System z (RUP for z)。然而，這種方法卻不能解決將幾個現(xiàn)有的方法整合統(tǒng)一化的問題， 4 就像在對一個已經(jīng)破壞的構架或者項目計劃修整的基礎上對現(xiàn)有的已定項目的修改一樣。 方法與軟件開發(fā) 業(yè)務驅(qū)動開發(fā)的關鍵原則，就像Per Kroll和Walker Royce 5 對軟件集約系統(tǒng)定義的那樣，在方法的環(huán)境中仍然可以普遍適用。因此，他們能夠很好地為改良的方法項目結果進行指導。這些原則是： - 調(diào)整過程。正確確定這個項目需求的開發(fā)過程是十分關鍵的。并不是越多越好，也不是越少越好。而是，一個項目所應用的正式程序的數(shù)量，精確度以及控制必須根據(jù)各種因素來確定，這些因素包括團隊的規(guī)模和分布，外部影響限制的數(shù)量，以及這個項目所處的狀態(tài)。
- 平衡競爭涉眾的優(yōu)先權。平衡經(jīng)常相沖突的業(yè)務和涉眾的需求是十分重要的，同樣，在這些需求滿足的條件下平衡自定義開發(fā)與資產(chǎn)重新利用也很重要。
- 跨團隊協(xié)作。 鼓勵最佳的項目范圍間的溝通非常重要。這可以通過正確的團隊組織和設置有效的合作環(huán)境來完成。
- 迭代地展示價值。 一個反復的過程允許開發(fā)團隊更好地適應變化，獲得反饋并將它分解到項目中去，從而盡早地減少風險，動態(tài)調(diào)整過程。
- 提升抽象層次：提高抽象層的水平有助于降低復雜性和項目所需的文檔的數(shù)量。可以通過重新利用，對高水平建模工具的使用，以及早期穩(wěn)定構架來達到。
- 持續(xù)關注質(zhì)量：在項目的整個生命周期都應該強調(diào)質(zhì)量的重要性。由于迭代過程能夠提供許多度量和修正機會，所以用它來達到高標準的質(zhì)量是非常適合的。
在將這些原則應用到方法開發(fā)中時，非常重要的一點是要切記它與軟件開發(fā)的不同和相同點。其中最大的不同可能是，方法開發(fā)強調(diào)生成文本的和圖形的內(nèi)容，這些都是靠網(wǎng)絡連接連通的，而且支持圖形模式；而軟件開發(fā)強調(diào)的是產(chǎn)生代碼。在方法開發(fā)項目中，沒有必要編寫和測試代碼，但是仍然需要測試所有的連接。 許多軟件需求技術對方法都是可適用的。比如用例，可以用來定義這個方法的范圍，鑒別那些利用此方法達到他們目標的研制人的不同類型（例如，典型的用戶），還可以詳細說明這些研制人是怎樣利用這方法來達到他們的目的的?？捎眯孕枨罂梢越⒃谟美桨负鸵恍┛捎眯砸蛩氐幕A上（學習的簡易性，對學習超時的保留，方案競爭的速度，或者主觀滿意度。）其它非功能性需求也十分重要，比如復雜性（調(diào)節(jié)方法水平的復雜性，從而使聽眾得到認可），組合型（將現(xiàn)有的插件方法組合起來的能力），或者本地化的能力（由于地域的差別，加強方法適應的能力）。 由于方法靜態(tài)的特征，靜態(tài)分析技術——尤其是方法檢查——在方法質(zhì)量中扮演了一個必須的角色。靜態(tài)分析包括分析方法元素來檢查他們是否對一些外在的或者內(nèi)含的道具表示滿意，比如內(nèi)容正確性，良好的信息顯示，或者與方法設計者指導法方針的遵從性。靜態(tài)分析要么是人工的，比如檢查，要么是自動化的，像拼寫和語法校驗。此外，動態(tài)驗證技術的應用，像測試仍然是可用的。比如，如果研制人是通過網(wǎng)站得知這個方法的，測試可能包括一些功能性的測試（例如，方法要在用例環(huán)境下進行測試）和可用性測試（例如，用例環(huán)境是不同用戶團隊中用可用性因素來測試的）。 在構架和設計水平，方法開發(fā)與軟件開發(fā)有許多相似之處。比如，構建一個方法庫，像RMC包括RUP和它的擴展。為了提供整合性，增強靈活性和增加重新利用的機會，構架組織也應該能夠做到松散地耦合與組件的高度粘合。方法架構一個非常重要的特征是它對變化和演變簡易性的適應性能。方法是需要修改和額外的時間的，尤其是在當今擁有不斷變化過程的世界。例如，您可能在某個時候為了合并遵從性和管理需要改變一個現(xiàn)有的方法。 最后，管理一個方法開發(fā)項目與管理一個軟件開發(fā)項目并沒有根本的不同。迭代與風險驅(qū)動開發(fā)的相同原則可以被成功地應用，并有助于團隊集中關注交付增量價值的問題。然而，方法開發(fā)項目的特性是，它至少涉及到兩個截然不同的生命周期：由方法開發(fā)團隊執(zhí)行的項目生命周期，以及構建階段的方法生命周期。項目經(jīng)理需要同時對這兩個生命周期都比較熟悉，可以通過由一個人來扮演項目經(jīng)理和方法設計人員兩個角色來實現(xiàn)。 方法開發(fā)工作產(chǎn)品 這個部分呈現(xiàn)了在方法開發(fā)項目中產(chǎn)生的必需工作產(chǎn)品。我將那些對方法開發(fā)比較特殊的工作產(chǎn)品與那些跟大多數(shù)開發(fā)工作類型相關的產(chǎn)品區(qū)分開來（例如，為了分辨這個項目的圖像和目錄）。 特殊的方法工作產(chǎn)品 一個方法首先要根據(jù)方法元素來定義。一個方法元素有可能是一個內(nèi)容元素（角色、任務、工作產(chǎn)品，或者內(nèi)容指南），或者一個過程元素（活動、能力模式，交付過程，或者過程指南）。查看表格1對不同類型方法元素的定義。 表格1：方法元素的不同類型和定義 | 方法元素 | | 內(nèi)容元素 | 過程元素 | - 角色。對一個或者幾個單個人員相關技能，資格以及影響力的設置。
- 任務。工作的可分配單元。每個任務都被分配到一個特定的角色。
- 工作產(chǎn)品。任務中任何被使用的，產(chǎn)生的或者修改的事物。
- 內(nèi)容指南。添加到內(nèi)容元素中的補充信息（例如，模板、樣例、工具向?qū)?，或者白皮書）?
| - 活動。對任務以及它們相關的角色和工作產(chǎn)品進行分組。為過程展現(xiàn)關鍵的構架板塊，可以用來構成效力模式或者交付過程。
- 能力模式。一系列可重新使用的活動。可以重新利用組成交付過程。
- 交付過程。端到端的完整項目生命周期。
- 過程指南。添加到過程元素的追加信息（比如，路線圖）。
| 一個方法元素可以從兩個不同的但是同等重要的角度來看：從方法設計師的角度，他定義了方法構架，因此可以確定方法元素和它們之間的關系；或者從方法作者的角度，他編寫方法元素的說明（比如，文本的和圖形的內(nèi)容）。由于方法開發(fā)的大量精力都花費在編寫方法元素上，所以第二個角度非常重要。由于這個原因，一個叫做方法元素描述（Method Element Description ）的分離工作產(chǎn)品被用來引用方法元素的內(nèi)容（即使方法元素描述工作產(chǎn)品包含于方法元素工作產(chǎn)品中）。 另外其它具體針對方法開發(fā)的必要工作產(chǎn)品歸納在表格2中，并有負責每個工作產(chǎn)品的角色。關于這些工作產(chǎn)品的附加信息緊跟在表格2的后面。 表格2：方法開發(fā)必要的工作產(chǎn)品，以及它們相關的角色 | 工作產(chǎn)品 | 角色 | 方法綱要
方法的框架，確定候選方法元素，還可能包含一些它們之間的相互關系和早期的描述。 | 方法設計師
瀏覽所有方法的定義。同義詞： 方法架構師、方法工程師、過程工程師。 | 方法定義
根據(jù)方法元素術語（包括他們的描述）和它們的相互關系對方法進行結構良好的定義，對一個或者更多的方法配置進行描述。 在RMC中，一個方法定義是一個復合的工作產(chǎn)品，包括所有的方法插件和與方法構建相關的方法配置。 - 方法插件
根據(jù)它的方法元素和它們的相互關系對方法組分（或者整個方法，如果僅用了一個組分來定義這個方法）進行結構良好的定義。
在RMC中，一個方法插件就是一個裝載方法包的容器。 - 方法包 在RMC中，一個方法包就是一個裝載方法元素（和其他方法包）的容器。
- 方法元素 內(nèi)容元素（角色、任務、工作產(chǎn)品，或者內(nèi)容指南）或者過程元素（活動、能力模式、交付過程、或者過程指南）。查看表格1中的定義。
方法配置
對方法結構的描述，或者這個方法的版本。 在RMC中，方法配置規(guī)定了如何在方法元素的基礎上構建一個方法Web站點，包括對方法插件 和方法包的篩選，以及將在方法Web站點的樹形瀏覽器中顯示的窗口。 | | 方法Web站點
方法開發(fā)項目的主要輸出。它使這個完整的方法，或者方法框架能夠順利展現(xiàn)在一系列互連的網(wǎng)頁上。 在RMC中，方法Web站點是自動從方法定義生成的（每個方法配置生成一個方法Web站點）。 注意這個工作產(chǎn)品是取決于圖形模式的。例如，如果您正在編寫一本方法書籍，那么這個方法Web站點就會被一本方法書取代。 | 方法元素描述
對內(nèi)容元素的描述（比如，文本的和圖形的內(nèi)容）。 | 方法創(chuàng)作
編寫方法元素的內(nèi)容。 | 在這個項目的前期，推薦利用一個方法綱要來概述這個方法。方法綱要的目標是幫助團隊鑒定候選方法元素和它們之間的一些關系，并為一些關鍵元素做出初始的描述。這種做法取決于這個項目的類型（從零開始創(chuàng)建方法，對現(xiàn)有的僅有內(nèi)容元素的方法的擴展，對現(xiàn)有的有內(nèi)容和過程元素方法的擴展等等。），方法綱要可能采取各種各樣的形式。比如，它可能包括一個或者更多以下的元素：生命周期的預排，對候選角色的簡潔描述、任務、工作產(chǎn)品，以及它們之間的關系；候選方法指導方針的列表（模板、例子、白皮書等等。）；早期的工作分解結構（WBS）；或者方法Web站點的模擬。方法綱要可能被存檔于源代碼中，文字處理器文件中、電子表格中，或者圖像模式中，或者利用任何其它的支持。這個免費的框架意味著要鼓勵創(chuàng)造性的思維，并允許團隊利用內(nèi)容、格式、符號來定義和檢查方法中一些最初的擬定，對最適合它們的需求和技巧起支持的作用。一旦一個新的方法，或者部分方法開始在方法綱要中形成，這個時候就應該運行Rational Method Composer，整個方法可以被更正式更完整地被定義。這時就可以拋棄方法綱要，繼續(xù)研究其它的觀念，比如發(fā)展成一個方法路標（過程指導），或者發(fā)展成一個所有方法元素的列表。在以后某些時候，可以用它來分派責任和跟蹤過程。 方法定義就是根據(jù)它的方法元素（包括它們的描述）和它們之間的關系對方法進行的一個結構良好的定義。方法定義同時還可以通過鑒別表現(xiàn)出一個或者更多結構或者方法版本，對于每一個結構，還可以鑒定研制人使用了哪些元素和怎樣使用的。在RMC中，如圖1所描述的那樣，方法定義是一個復合的工作產(chǎn)品，包括所有的方法插件和被構建的方法相關的方法配置。換句話說，一個方法定義對應著被構建方法相關的RMC庫子集。 方法插件是一個根據(jù)方法元素（包括它們的描述）和它們的相互關系對方法成分進行的結構良好的定義。在RMC中，一個方法插件就是一個方法包的容器，而這個容器反過來又包含著方法元素和其它潛在的包。方法插件和方法包允許在適當?shù)牧６人浇M織方法元素。這種水平的粒度需要腦子里自始至終對重新使用有相當仔細的考慮。的確，方法插件和方法包都是方法配置可重用的組分。 方法配置是對方法（如小項目的RUP和大項目的RUP）的一個版本的描述。在RMC中，一個方法配置可以規(guī)定怎樣用精選的方法插件和方法包中的方法元素來組成方法Web站點（因為您可能不想公布在特定配置環(huán)境下這個方法所詳細定義的所有方法元素）。這個方法配置同時還規(guī)定了將在方法Web站點樹形瀏覽器中顯示的窗口。 方法Web站點是一個方法開發(fā)項目的主要成果。它通過一系列相互連接的網(wǎng)頁使最新定義的方法，或者方法框架能夠展現(xiàn)給研制人員。在RMC中，方法Web站點是從方法定義（一個方法配置生成一個方法Web站點）中自動生成的。圖2提供了方法Web站點的例子。注意整個工作產(chǎn)品所呈現(xiàn)的形式取決于表達模式。例如，如果您編寫一本方法書，那么這個就會被一本方法書取代。 為了總結構成方法定義不同成分的角色，我將使用專門的打折銷售成套書籍的書店來類比：一個方法插件可比作書店的一個部門（旅游、喜劇、兒童等等。），方法包可比作一套打包出售的書，方法元素可比作單本的書籍，方法配置可比作您的購書目錄，方法Web站點可比作購物袋，您在購物結束后帶回家的那些書。 圖1：RUP for z 在 RMC 中的方法定義的例子，包括發(fā)布在RUP for z 方法Web站點的選定的元素 圖1提供了一個RUP for z 的 RMC 的方法定義的例子，包括三個方法插件（rup、rup_for_soa 和rup_for_z，因為插件是通過擴展rup和rup_for_soa來定義的）和一個方法配置（RUP for z 配置）。盡管這個方法定義包含三個方法插件，但是只有一個rup_for_z插件在RUP for z方法開發(fā)成果的范圍之內(nèi)。（rup and rup_for_soa在范圍之外是因為它們在這個項目過程中沒有被修改）。RUP for z 配置決定了RUP for z發(fā)布在網(wǎng)站上的內(nèi)容。在整個簡單的例子中，這個網(wǎng)站將包括rup的方法內(nèi)容包的內(nèi)容元素（rup的Processes包已經(jīng)被過濾掉），rup_for_soa的方法內(nèi)容包的內(nèi)容元素（rup_for_soa的Processes包已經(jīng)被過濾掉），還有rup_for_z的所有方法元素（來自方法內(nèi)容和過程包）。從業(yè)者們將能夠通過圖1中View欄中顯示的導航樹來操作這個網(wǎng)站。 圖2顯示了一個RUP for z 的方法Web站點例子，它來自顯示在圖1中的方法定義。 圖2：RUP for z的方法Web站點的例子 從新創(chuàng)建方法的例子中，方法定義在這個項目的開始是空白。在一個自定義方法中，方法定義已經(jīng)包含了與現(xiàn)有方法相關的插件——但并不包含現(xiàn)有的配置，然而，由于一種配置是專門為特定的方法設定的，因此并不是一種可重新使用的資產(chǎn)。例如，為了創(chuàng)建一個RUP for z的自定義版本，您可以用方法定義來開始，包括圖1中所顯示的插件。然后您可以添加，至少可以增加：一個新的方法插件（涉及到現(xiàn)有的插件：rup, rup_for_soa, and rup_for_z），是專門給您的新方法規(guī)定方法元素；和一個新方法配置，用來對您的新方法Web站點進行配置。您的新方法元素可以由新創(chuàng)建或者利用相互關系的變量對現(xiàn)有方法的一些元素進行衡量 6 （例如，貢獻、擴展，或者代替）。 現(xiàn)在是明確地定義兩個我曾在上面間接提到過術語的最佳時機： - 方法架構是根據(jù)重要的構件和它們之間的相互關系對這個方法結構的闡述。
- 方法設計也涉及到方法的結構，包括所有的構件和它們之間的關系。
在RMC中的構件是方法插件、方法包，、方法元素和方法配置。 注意對方法架構和方法設計是不需要新的工作產(chǎn)品的，因為它們是在RMC中直接被定義的，并且在方法定義工作產(chǎn)品范圍內(nèi)。那就是說，除非這個團隊注意到了要在分離的工作產(chǎn)品中捕獲它們的需要，比如，像一個構架文檔和一個圖形模式——它們都是定義復雜的方法的很好的例子。 支持的工作產(chǎn)品 除了我剛才所描述的專門針對方法開發(fā)的必需工作產(chǎn)品以外，盡管事實上這篇文章所描述的方法著重強調(diào)的是開發(fā)真正的方法而不是產(chǎn)生項目相關的文檔，卻可能會不時對產(chǎn)生一些支持這個開發(fā)工作的額外工作產(chǎn)品有所幫助。在這個部分我介紹了一些工作產(chǎn)品，雖然不是專門針對方法開發(fā)的，但是已經(jīng)被證明可以支持各種大量的方法開發(fā)工作。類似的工作產(chǎn)品在其它方法中也能找到，像OpenUP/Basic 7 或者RUP本身。在一定程度上您要根據(jù)許多因素將這些支持的工作產(chǎn)品形式化，包括項目復雜性，開發(fā)組織的文化，以及項目管理動態(tài)。 由于每個項目都需要一個獲取所有涉眾期望，項目規(guī)模，以及需求和限制的來源，我建議將這個信息存檔到愿景文件中。愿景可以充當顧客和開發(fā)組織之間的契約。 由于我堅定地相信迭代和風險驅(qū)動方法對方法開發(fā)帶來的好處，所以我建議利用一個項目計劃來有效的執(zhí)行這個方法。這個項目計劃規(guī)定了這個項目的狀態(tài)和重要事件。它可能包含一個能夠定義每次迭代詳細情況的迭代計劃（比如，就分配有資源的任務來說）；迭代評估將評估一次迭代的結果并執(zhí)行必要的中間修正；另外風險列表對風險進行鑒定和對它們進行優(yōu)先劃分，還要詳細說明必需的處理或者緩解突發(fā)事件的行動。 表格3總結了被推薦的支持這個方法開發(fā)工作的工作產(chǎn)品 表格3：支持的工作產(chǎn)品和它們的相關角色 | 工作產(chǎn)品 | 角色 | 愿景
獲取涉眾對被開發(fā)方法的看法，以及對方法規(guī)模，需求和限制的觀點。 | 分析師
通過搜集他們所輸入的信息推定需要解決的問題，和通過為需求獲取和設定優(yōu)先權，從而提出涉眾所關注的問題。 | 項目計劃
搜集所有管理這個項目的需要的信息。它的主要部分由一個大概的計劃組成，包括項目狀態(tài)和重要事件。包括以下幾點： - 迭代計劃（每次迭代都有個計劃）
一個周密的計劃描述了工作的目標，工作分配，以及每次迭代的評估標準。 - 迭代評估（每次迭代都有一次評估）
獲取一次迭代的結果，評估標準所達到的程度，教訓的總結，以及需要做的更改。 - 風險列表
項目中已知的和未知的風險列表，還附有具體的緩解方法和處理偶發(fā)事件的行動。 | 項目經(jīng)理
領導這個項目的計劃，并使涉眾與計劃的相互關系協(xié)調(diào)起來，保持項目團隊能夠集中精力來達到項目的目標。在大多數(shù)方法開發(fā)項目（異常復雜的例子除外）中，項目經(jīng)理和方法設計師角色是由同一個人擔任的。 | | | | 方法開發(fā)路線圖 在本文所提出的方法開發(fā)的方法，是基于四個RUP的階段：先啟、精化、構建和產(chǎn)品化。本章節(jié)帶您快速瀏覽一下一個典型項目的每個階段。 先啟階段 這個部分描述了一個方法開發(fā)項目的先啟階段，包括它的主要目標，評估標準，在最后階段必要工作產(chǎn)品的狀態(tài)，以及基本的任務。 先啟目標 先啟階段的主要目標是在這個項目目標的基礎上使涉眾能夠通力合作，并使他們接受這個項目是值得去完成的。 先啟評估標準 在先啟階段的末尾，這個項目要根據(jù)以下的標準來評估： - 涉眾在規(guī)模、需求，限制以及進度評估上的合作。
- 所有的風險都被鑒定，并且針對每個風險都有一個緩解方法或者處理偶發(fā)事件的策略。
- 這個方法開發(fā)環(huán)境能夠就地支持精化階段。尤其是配置管理環(huán)境（比如IBM Rational ClearCase?）和方法開放環(huán)境（比如RMC）應該設置。
- 這個團隊已經(jīng)受到很好的訓練，因此他們已經(jīng)準備好開始精化階段了。
如果這個項目不能達到這些標準，就可能會被放棄或者被重新認真考慮。 在先啟階段的末尾基本工作產(chǎn)品的狀態(tài) - 愿景。 涉眾的期望，項目的范圍，需求以及約束都被存檔。
- 項目計劃。 在這個階段，它們的持續(xù)時間和目標都被明確定義。最初精化迭代的迭代計劃已經(jīng)完成并核查。最初的項目風險也已經(jīng)確定。
- 方法綱要（可選）。 早期的可能處理非常特殊的風險。
基本任務在中一次典型的先啟迭代中被執(zhí)行 先啟階段的工作產(chǎn)品是通過執(zhí)行圖3所示的任務來完成的。注意其它的任務和工作產(chǎn)品可能適用（比如設置這個方法開發(fā)的環(huán)境和對團隊人員進行培訓），但是很少被推薦。圖3所表述了涉眾的角色都是利害關系人，比如顧客、從業(yè)者和問題專家 (SME)，他們?yōu)榱舜_保團隊構建了一個正確的方法，并能按時在預算之類完成，驅(qū)動先啟階段的所有任務。 圖3：先啟階段的基本任務，還有相關的角色和輸入/輸出工作產(chǎn)品 表格4描述了綱要方法任務。這個任務獨立于項目團隊所采取的實際策略來定義這個方法，例如，自頂向下的（根據(jù)狀態(tài)和它們的目標對整個生命周期的定義使得內(nèi)容元素的鑒定更為便利）或者自底向上的（對內(nèi)容元素的定義促使了生命周期的鑒定）。在實踐中，項目團隊通常聯(lián)合使用這兩種策略，這樣促使了更多聯(lián)合方法的產(chǎn)生，從這種意義上說每個內(nèi)容元素能夠更明確地連接在一個或者更多的階段目標中。 例如，RUP for System z 8 方法的核心是利用一個自頂向下的策略來定義的，是在為期兩個多周一系列自由討論會議的背景下完成的。這些自由討論的結果歸檔在方法綱要中。首先，z 的從業(yè)者們?yōu)榱诉m應z環(huán)境的特殊需求，被要求對每個RUP階段進行檢查 ，鑒定它的主要目標和交付產(chǎn)品的任何一個必要變化。這樣使得團隊成員能夠鑒定第一批需要被添加到RUP來滿足z群體需求的工作產(chǎn)品（比如模塊和安裝驗證過程），并且與最初RUP階段的目標適用于z 的事實達成一致。第二，z的從業(yè)者們被要求對他們今天所執(zhí)行的高水平的活動進行描述，這樣使他們能夠達到每個階段的目標。允許團隊對每一個階段，對按照一定順序的有代表性的迭代或者高水平活動的聯(lián)合進行詳細說明。第三，z的從業(yè)者們被要求對按照不同角色執(zhí)行的任務（和潛在的附加活動）分組和工作產(chǎn)品的生產(chǎn)進行詳細說明；有多少現(xiàn)有的RUP元素就要執(zhí)行多少工作。這樣團隊可以確定要被添加到RUP for z中的一系列的任務（比如模塊設計和定義安裝驗證過程）和相關角色以及工作產(chǎn)品。這種策略引導出一個當前應用在z環(huán)境中描述軟件開發(fā)實踐的端到端的過程和衡量包含于RUP中一些任務、角色、工作產(chǎn)品，活動以及現(xiàn)代最佳實踐的定義。這個度量還確保了每個方法元素能夠清晰地依靠一個或者更多的階段目標。 表格4：綱要方法任務的描述 任務：
綱要方法 | 這個任務概述了方法綱要中的方法。它確定了候選方法元素和它們之間的一些關系，并對一些關鍵元素做了初始的描述。在這個任務執(zhí)行中一些潛在的相應步驟如下面所提到的（沒有具體的次序）： | | | - 確定方法開發(fā)策略（像自頂向下和自底向上）。
- 檢查現(xiàn)有的資產(chǎn)并確定可重復使用的機會。
- 確定與這個新方法相關的候選方法元素——內(nèi)容和過程。如果可以，將這個項目范圍之內(nèi)的元素與項目范圍之外的元素區(qū)分開來（因為它們已經(jīng)出現(xiàn)在現(xiàn)有方法中并能夠被重復數(shù)用）。
- 確定候選方法元素之間的候選關系（比如，哪個角色是負責工作產(chǎn)品的）。
- 為一些關鍵候選方法的元素進行初始的概述。
- 從涉眾那里獲取對方法綱要的返回信息。
| 精化階段 這個部分根據(jù)一個方法開發(fā)項目的主要目標，評估標準，此階段結束時基本工作產(chǎn)品的狀態(tài)和基本任務，對它的精化階段進行了描述。 精化目標 精化階段的主要目標是調(diào)整的基線，為構建階段中大量的編寫工作提供一個穩(wěn)定可靠的基礎。這個構架的穩(wěn)定性是根據(jù)一個或者多個方法Web站點來評估的。 精化的評估標準 在精化階段的末尾，這個項目是根據(jù)以下的標準來評估的： - 需求都很穩(wěn)定。
- 方法架構比較穩(wěn)定。
- 對絕大多數(shù)重要方法元素的描述相當穩(wěn)定。
- 通過對一個或者多個方法Web站點的評估證明主要風險元素已經(jīng)被處理完畢。
- 構建階段的迭代計劃非常詳細，并促進工作繼續(xù)進行。
- 在當前構架的背景下，如果執(zhí)行當前的計劃能夠開發(fā)完整的方法，所有的涉眾都認為目前的設想是可以實現(xiàn)的。
如果這個項目不能達到這個標準，這個項目就會流產(chǎn)或者被重新考慮。 精化階段結束時基本工作產(chǎn)品的狀態(tài) - 方法綱要。 所有重要的候選方法元素和它們之間的關系都被確定。這個方法概述可能還包括一些關鍵元素的早期描述。這個概述已經(jīng)被檢查并受到贊同；比例，每個候選方法元素將變成一個方法定義的方法元素。
- 方法定義。 方法架構是原始資料。它包括所有重要的結構元素（方法插件包括方法包和方法元素，以及方法配置）和它們之間的關系。它權衡了現(xiàn)有的可用資產(chǎn)。方法設計的定義可能還不夠完善。它包括非重要結構元素和它們之間的相互關系。
- 方法元素描述。 絕大多數(shù)方法元素的描述都比較粗糙，要么直接在RMC中要么使用任何其它的編輯器。重要的方法元素的描述都編寫得非常完整并且都經(jīng)過核查。
- 方法Web站點。 為了研究方法的重要問題和評估的可用性產(chǎn)生了一個或者更多的網(wǎng)站。
- 愿景。 窗口基于在這個階段獲取的新信息而得到改進的，這樣就建立了一個對大多數(shù)關鍵需求穩(wěn)定的認識，促使構架與計劃的決策的形成。
- 項目計劃。 項目計劃是最新的并且擴展到能夠覆蓋到構建和產(chǎn)品化階段。最初構建迭代的迭代計劃已經(jīng)完成并且被核查過。構建中隨后迭代的迭代計劃也已經(jīng)設計好了。風險已經(jīng)被校正并且核查過。
基本任務在精化中一個具有代表性迭代中執(zhí)行 精化階段中專門針對方法開發(fā)的工作產(chǎn)品是通過執(zhí)行圖4中顯示的任務而產(chǎn)生的。注意其它的任務和工作產(chǎn)品可能也可以應用（比如，為了測試網(wǎng)站），但是我們并不推薦使用。圖4中任務的執(zhí)行應該受到一個清晰的愿景和項目計劃的驅(qū)動， 無論它們是什么樣的形式。方法評審者包括主要的同行和其他領域問題專家(SME)。然而，在評估這個方法的時候我們還建議有其他涉眾的參與，像從業(yè)者和顧客，依次來確保這個方法是可用的，且能夠滿足涉眾的需求。 圖4：精化階段中詳細的方法基本任務，還有與它們相關的角色和輸入/輸出工作產(chǎn)品 表 5 提供了構造方法任務的描述。 表格5提供了對構造方法任務的描述 任務：
構造方法 | 這個任務根據(jù)方法插件、方法包、方法元素，方法配置和它們之間的關系構建了這個方法。在這個任務執(zhí)行中一些潛在的相關步驟如以下所示（沒有詳細的順序）： | | | - 如果可以，檢查現(xiàn)有的方法插件結構形成這個新方法基礎的過程。
- 定義與這個新方法相關的方法插件和對其他插件的相互依存關系，如果可以的話。
- 在合適的插件中定義方法包。
- 在合適的包中定義方法元素和它們的相互關系，包括評估現(xiàn)有資產(chǎn)的變量關系。
- 對方法元素進行邏輯分類（可以用標準的或者RMC中自定義分類來完成）。
- 定義導航窗口（可以用RMC中自定義分類來完成）。
- 通過選擇一套將發(fā)布的方法插件的和方法包，以及導航窗口來定義方法配置。
- 從涉眾獲得關于這個方法結構的反饋。
| 構建階段 這個階段根據(jù)它的主要目標、評估標準，此階段結束時基本工作產(chǎn)品的狀態(tài)和基本任務對方法開發(fā)項目的構建階段進行了描述。 構建目標 構建階段的主要目標是基線構架的基礎上完成這個方法的開發(fā)工作，并且為這個從業(yè)團體準備一個產(chǎn)品化質(zhì)量的方法。 構建評估標準 在構建階段結束時，這個項目是按照以下標準來評估的：在從業(yè)者社區(qū)這個方法足夠穩(wěn)定成熟，以至于可以在社區(qū)中進行配置。 如果這個項目不能達到這個標準，產(chǎn)品化階段就會被延遲。 構建階段結束時基本工作產(chǎn)品的狀態(tài) - 方法定義。 方法設計師已經(jīng)有詳細的定義。它包括所有的結構元素（方法插件包括方法包和方法元素，和方法配置）和它們之間的關系。
- 方法元素描述。方法元素的描述已經(jīng)完成并且核查過，比如它們都存在于RMC中。
- 方法Web站點。一個覆蓋全部方法的網(wǎng)站已經(jīng)產(chǎn)生。這個網(wǎng)站已經(jīng)進行了識別缺陷的測試，像斷開的連接，或者結果的可用性。
- 項目計劃。 最初構建迭代的迭代計劃已經(jīng)完成并且被核查過。構建中隨后迭代的迭代計劃也已經(jīng)設計好了。風險已經(jīng)被校正并且核查過。
在構建階段的一個典型迭代中執(zhí)行的基本任務 構建階段中專門針對方法開發(fā)的工作產(chǎn)品是通過執(zhí)行圖5中顯示的任務而產(chǎn)生的。注意其它的任務和工作產(chǎn)品可能也可以應用（比如，為了測試網(wǎng)站），但是我們并不推薦使用。圖5中任務的執(zhí)行應該受到一個項目計劃的驅(qū)動， 無論它們是什么樣的形式，這樣構建階段的每一次迭代中需要完成是什么就顯而易見，因此這個團隊就能夠集中精力盡快交付結果，因為創(chuàng)造性的進程在后面驅(qū)使著他們。方法評審者包括主要同行和其他領域問題專家 (SME)。然而，在評估這個方法的時候我們還建議有其他涉眾的參與，像從業(yè)者和顧客，依次來確保這個方法是可用的，且能夠滿足涉眾的需求。 圖5： 構建階段中詳細的方法基本任務，還有與它們相關的角色和輸入/輸出工作產(chǎn)品 產(chǎn)品化階段 這個階段根據(jù)它的主要目標、評估標準，在最后階段必要工作產(chǎn)品的狀態(tài)，以及基本的任務對方法開發(fā)項目中的產(chǎn)品化階段進行了描述。 產(chǎn)品化目標 產(chǎn)品化階段的主要目標是確保為從業(yè)者提供一個優(yōu)良質(zhì)量的可利用的方法。 產(chǎn)品化評估標準 在產(chǎn)品化階段的最后，這個項目要按照以下標準來進行評估：這個方法已經(jīng)分配到從業(yè)者團體中，并且從業(yè)者對此感到滿意。 如果這個項目不能達到這個標準，這個項目的結束不得不通過依次的延遲發(fā)布版本來完成。 在產(chǎn)品化階段的最后，發(fā)布版本的維護循環(huán)就開始了。這可能包括開始一個新的循環(huán)，或者一些額外的維護版本。 產(chǎn)品化階段末尾基本工作產(chǎn)品的狀態(tài) - 方法定義。方法插件（包括方法元素描述）和方法配置已經(jīng)完成，并且與這個需求保持一致。來自審核人員的反饋也應該考慮。
- 方法Web站點。一個覆蓋完全方法的網(wǎng)站已經(jīng)產(chǎn)成（測試過程中鑒別的問題已經(jīng)被確定）。
在產(chǎn)品化階段中的一個典型的迭代執(zhí)行的基本任務 產(chǎn)品化階段中專門針對方法開發(fā)的工作產(chǎn)品是通過執(zhí)行圖6中顯示的任務而產(chǎn)生的。注意其它的任務和工作產(chǎn)品可能也可以應用（比如，為了測試網(wǎng)站），但是我們并不推薦使用。圖6中任務的執(zhí)行應該受到一個項目計劃的驅(qū)動， 無論它們是什么樣的形式，這樣產(chǎn)品化階段的每一次迭代中需要完成是什么就顯而易見。因為創(chuàng)造性的進程在后面驅(qū)使著他們。這時方法評審者包括主要從業(yè)者，因為這個方法是在"beta"下進行評估的。然而，在評估這個方法的時候我們還建議有其他涉眾的參與，像顧客，在方法評估過程中能夠確保在這個項目結束之前滿足涉眾的需求。 圖6：產(chǎn)品化階段中詳細的方法基本任務，還有與它們相關的角色和輸入/輸出工作產(chǎn)品 結論 這篇文章描述了一個迭代的、風險驅(qū)動的、以構架為中心的，以及面向質(zhì)量的方法開發(fā)的方法。這個方法通過瀏覽一個方法開發(fā)項目的每個階段來展現(xiàn)，根據(jù)以下幾個方面：項目的主要目標、評估標準，在最后階段必要工作產(chǎn)品的狀態(tài)，以及這個階段所執(zhí)行的基本任務。 這個方法已經(jīng)被執(zhí)行和改進可許多年——還將繼續(xù)被改進——在大量不同項目的背景下進行的：從通過工具指導來處理一個特殊的技術問題而對RUP進行相當簡單地擴展，到通過各種指導方針，額外的內(nèi)容元素和改進的生命周期來處理特殊的域而進行相當復雜的擴展（像RUP for COTS 9, 10 ）。在執(zhí)行的過程中這個方法被存檔在RUP for System中，并與一個中度或者高度復雜的典型方法開發(fā)工作相一致（一個五人團隊，十四個周的項目期限，一個可交付的插件，一個可交付使用的配置，以及大約八十個新內(nèi)容和過程元素）。 當前的這個方法被普遍看作一個稱為Method Authoring Method Basic (MAM Basic)的RMC方法。這篇文章僅僅是對RUP團隊所追求的對方法開發(fā)過程形式化的一個初步嘗試。由于方法開發(fā)是一個大家興趣逐步增長的領域，希望看到更多來自方法開發(fā)社區(qū)的指導、相關的各種話題，像方法架構、方法迭代或者方法配置管理。 感謝 我想感謝所有審核人員的貢獻，感謝他們對這篇文章初稿的深刻見解。特別感謝Carlos Goti詳細的評論和他始終精辟的建議，感謝RUP for System z團隊對這個方法執(zhí)行得如此徹底，并提供了建設性的反饋。最后，由于這篇文章所展現(xiàn)的方法來自多年來RUP和IRUP團隊工作的努力，所以我要感謝這兩個不平凡的團隊中的每一個同事。 注釋 1 Per Kroll和Philippe Kruchten。Rational Unified Process Made Easy: A Practitioners Guide to the RUP。2003年Addison-Wesley出版。 2在這篇文章中我講述了兩個方法的開發(fā)，意味著不用制定直接在項目中執(zhí)行；對于方法框架，意思是為滿足一個項目或者組織的特殊需求需要進一步地制定。為了簡便起見，在整篇文章中我使用方法一詞來表達方法和方法框架兩種意義。 3為了解更多的RMC信息，請查看以下的資源： 4一個關于使用RMC簡單方法自定義的良好信息資源是：IBM Global Services Course description: PRJ350v2 Essentials of Tailoring Methods with Rational Method Composer, v7.0.1.。 5 Per Kroll 和 Walker Royce， The Rational Edge，2005 年 12 月： 業(yè)務驅(qū)動開發(fā)的關鍵原則。 6 要得到更多關于可變性的信息，請參考 IBM Global Services course PRJ350v2。 7 要得到更多信息，請訪問： http://www.eclipse.org/epf/。 8 要得到更多關于 System z 的信息，在以下 2007 年 2 月末的刊物中可以得到： 9 要得到更多的信息請訪問：IBM Rational Method Composer (RMC) 7.1 Plug-ins。 10 Cécile Péraire and Russell Pannone， The Rational Edge， 2005 年 10 月， 基于 COTS 項目的 IBM Rational Unified Process：介紹。
參考資料
關于作者 | | | | Cécile Péraire 是 IBM 的一個方法構架師和作者，對 IBM 軟件開發(fā)方法的定義有很大的貢獻，包括 Rational Unified Process (RUP) 及它的一些最重要的擴展。在加入 IBM Rational Unified Process 團隊之前，Cécile 是 Rational 的一位高級顧問，幫助顧客使用 Rational 方法和工具。她在軟件工程領域大約有16年的工作經(jīng)驗。Cécile 在洛桑的瑞士聯(lián)邦工藝學院獲得了軟件測試的博士學位。 | | 
