當一個組織引進了一組最佳實踐，如ITIL，并提供了一個采用要求，它將面對若干挑戰，這些挑戰至少是與可執行過程相關的。我們必須解釋一下非可執行過程。例如，在工作流還沒有被定義時，采用者必須從實踐集里導出工作流。這需要對實踐的廣泛分析來確定組織或角色依賴性，工件所有權，管理方法，等等。就內容和模板及報告的格式發生大規模辯論也不足為奇。我曾見過這種分析持續幾個星期，甚至幾個月，但仍然得不出令人滿意的輸出。最后，過程采用意味著組織變化。成功的一個關鍵因素是能夠清楚地為受到新過程影響的人定義：
它們起到什么作用。
它們被希望擁有哪些技能和競爭力。
對某個作用來說，任務是什么。
它們需要對哪些工件負責，為什么。
它們如何作為一個整體與其它整體協作。
它們如何知道它們是否成功。
可執行過程需要很長時間來解答這些問題。RUP提供了一個關鍵元素：過程調整指導。過程被原封不動地采用，沒有提供任何針對不同的項目復雜性或團隊技術水平的靈活性；這種現象太常見了。
可執行ITIL
怎樣才能使一個過程是可執行的呢？首先，它需要包含關鍵元素，如圖2所示。
圖2：RUP組件
圖2顯示了RUP中隱含的過程元模型。這一方法是基于對象管理組(OMG)的，稱為軟件過程工程元模型(SPEM)。它提供了對使用統一建模語言(UML)的過程的各個方面的完整覆蓋。要使ITIL成為可執行的，這些元素必須被明確和記錄為文檔。此外，相互關系和依賴性也必須被確定，這樣，最終，一個工作分解結構(WBS)可以被產生。
完成這一工作的步驟是相當直接明顯的，盡管如此，工作量卻不小。我們用來建立ITIL文檔的工作流如下：
定義過程的最高級分解。這有助于組織工作和管理依賴性。這些過程“桶”被轉化為規范。
明確角色和角色群如果你熟悉RUP，你就會知道一個角色群，比如分析員，包括了系統分析和需求細化兩個功能。
確定工件或工作產品。這是過程執行的確實的輸入/輸出，可以是從文檔到一個工具中的配置設置中的任何東西。
明確任務。我們遵從一種與用例分析相似的方法，在該方法中我們按照作用尋找任務，然后作為精化步驟，評估任務的通用性。記住，任務（RUP活動）分解為步驟，而作為常規指導，我們試圖使所有活動的步驟保持在大約10個以下。
定義已導出元素間的關系。我們把角色作為基本單元，并在初始時把所有關系與它們進行關聯。接著，我們將在領域內評估元素間的關系（比如，角色與其他角色的關系，工件與其它工件的關系，等等）。
創造工作流。工作流是任務的匯合，它定義順序和同步（哪些任務可以并行進行，哪些不行），以及依賴性。在某些情況下，這一步驟可以在步驟4前完成，但是正如我們在Rational新的為過程建模的方法中可以看到的，現在的順序要相對好一些。
收集指導，清單，工具指南，等等。這些元素將為過程采用，使用，和管理提供便利。
結果具體分析。在過去，我們使用Rational Process Workbench (RPW)來產生對RUP的修改�，F在我們用Rational Method Composer取而代之。下面我們將介紹這一工具。
IBM Rational Method Composer
如果你已經使用了Rational過程空間一段時間并曾嘗試定制化RUP，你可能會熟悉Rational Process Workbench (RPW)。它是一個基于Rational Extended Development Environment (XDE)的過程管理工具。盡管它是一個強大的工具，很多人覺得它很難使用。那么試試Rational Method Composer (RMC)，它與RPW是完全不同的。
首先，RMC的規模比RUP大。在包含了RUP內容庫的同時，用戶還可以使用RMC創造或定制化任何過程。其次，和IBM Rational的許多新產品一樣，它是基于Eclipse的，這意味著它擁有工業標準的外觀和感覺。最后，對沒有建模背景的用戶來說，RMC更容易使用。你還是需要掌握分析技術，最好也有項目管理背景，但是你不需要是UML專家來使用這個工具。
方法：RMC基礎
文章來源于領測軟件測試網 http://www.kjueaiud.com/
