当一个组织引进了一组最佳实践，如ITIL，并提供了一个采用要求，它将面对若干挑战，这些挑战至少是与可执行过程相关的。我们必须解释一下非可执行过程。例如，在工作流还没有被定义时，采用者必须从实践集里导出工作流。这需要对实践的广泛分析来确定组织或角色依赖性，工件所有权，管理方法，等等。就内容和模板及报告的格式发生大规模辩论也不足为奇。我曾见过这种分析持续几个星期，甚至几个月，但仍然得不出令人满意的输出。最后，过程采用意味着组织变化。成功的一个关键因素是能够清楚地为受到新过程影响的人定义：
它们起到什么作用。
它们被希望拥有哪些技能和竞争力。
对某个作用来说，任务是什么。
它们需要对哪些工件负责，为什么。
它们如何作为一个整体与其它整体协作。
它们如何知道它们是否成功。
可执行过程需要很长时间来解答这些问题。RUP提供了一个关键元素：过程调整指导。过程被原封不动地采用，没有提供任何针对不同的项目复杂性或团队技术水平的灵活性；这种现象太常见了。
可执行ITIL
怎样才能使一个过程是可执行的呢？首先，它需要包含关键元素，如图2所示。
图2：RUP组件
图2显示了RUP中隐含的过程元模型。这一方法是基于对象管理组(OMG)的，称为软件过程工程元模型(SPEM)。它提供了对使用统一建模语言(UML)的过程的各个方面的完整覆盖。要使ITIL成为可执行的，这些元素必须被明确和记录为文档。此外，相互关系和依赖性也必须被确定，这样，最终，一个工作分解结构(WBS)可以被产生。
完成这一工作的步骤是相当直接明显的，尽管如此，工作量却不小。我们用来建立ITIL文档的工作流如下：
定义过程的最高级分解。这有助于组织工作和管理依赖性。这些过程“桶”被转化为规范。
明确角色和角色群如果你熟悉RUP，你就会知道一个角色群，比如分析员，包括了系统分析和需求细化两个功能。
确定工件或工作产品。这是过程执行的确实的输入/输出，可以是从文档到一个工具中的配置设置中的任何东西。
明确任务。我们遵从一种与用例分析相似的方法，在该方法中我们按照作用寻找任务，然后作为精化步骤，评估任务的通用性。记住，任务（RUP活动）分解为步骤，而作为常规指导，我们试图使所有活动的步骤保持在大约10个以下。
定义已导出元素间的关系。我们把角色作为基本单元，并在初始时把所有关系与它们进行关联。接着，我们将在领域内评估元素间的关系（比如，角色与其他角色的关系，工件与其它工件的关系，等等）。
创造工作流。工作流是任务的汇合，它定义顺序和同步（哪些任务可以并行进行，哪些不行），以及依赖性。在某些情况下，这一步骤可以在步骤4前完成，但是正如我们在Rational新的为过程建模的方法中可以看到的，现在的顺序要相对好一些。
收集指导，清单，工具指南，等等。这些元素将为过程采用，使用，和管理提供便利。
结果具体分析。在过去，我们使用Rational Process Workbench (RPW)来产生对RUP的修改。现在我们用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基础
文章来源于领测软件测试网 https://www.ltesting.net/
