使用Rational Method Composer赋予ITIL可执行性（1）

Corby James, Chief Technologist and Principal, Noblestar

2006 年 3 月 15 日

本文来自于 Rational Edge：这篇文章探讨了信息技术基础结构库(ITIL)，可执行过程，以及IBM Rational Method Composer可以怎样被组合起来以从健壮，加强的过程中获得最大的价值。

如果本文的标题引起了你的注意，那么可能是因为你对以下：ITIL，可执行过程，以及新的IBM Rational Method Composer三者中的一或多个感兴趣。所有这些都是值得进一步研究的重大主题。在本文中，我将就这些主题给出足够信息，使你在下次用户会议上可以与人交流，但是当然，这对使你在任意一个领域中掌握丰富的技术是不够的。我想要说明的是，这些概念可以怎样进行组合，使得你能从它们中获得价值。

什么是ITIL？

对Rational Edge的长期读者来说，你可能习惯于见到关于Rational Unified Process (RUP)，eXtreme Programming (XP)以及项目管理知识体(PMBOK)的文章。但是ITIL究竟是什么呢？

ITIL表示信息技术基础结构库，它被认为是IT服务管理(ITSM)最佳实践的全球标准。虽然像RUP，XP等开发方式是针对软件开发领域的，ITIL却是面向整个IT操作领域的。它于二十世纪八十年代中期在英国建立，建立者是政府商业办公室(OGC)，目的是作为一种向应用程序和基础结构管理引入一些严格性和统一性的方式。

ITIL是以一套7册的书的形式发布的，这些书介绍了：

服务支持
服务提供
计划实现服务管理
ICT基础结构管理
应用程序管理
安全性管理
商业前景
尽管每一本书都提供了宝贵的见解，大多数没有接触过ITIL的公司却更倾向于学习服务发布和服务支持。服务发布可分解为以下领域：

可用性管理描述了如何定义应用程序和基础结构的最大失效时间和平均失效时间。它主要研究服务能力，恢复能力，可靠性等等概念。
能力管理描述了如何确定基于定义的服务水平有足够和适当的资源。
连续性管理涉及的是管理错误恢复和掉电的实践。
金融管理包括了如何计算基础结构成本和最优化成本的实践。
服务水平管理既考虑了面向用户的确定时间上限的实践，也考虑到了帮助用户理解支持成本与服务水平之间的平衡的实践。
服务支持包含如下方面：

配置管理在这一上下文中指的是，明确和控制基础结构类型的资产或配置项(CIs)。因此在软件配置管理处理控制代码，模型元素，等等的地方，ITIL CIs可以充当硬件，中间件，终端用户应用程序，等等。
变更管理描述了配置项的变化应如何发生。其描述的活动与标准软件变更管理的活动有很多重叠。
意外管理细化了非正常操作过程的元素应如何被处理。它包括对意外的分类，这样就可以通过设置优先级顺序来决定如何对意外做出应对。
问题管理与意外管理是相关的，因为意外经常是由问题，错误，缺陷，等等造成的。问题管理描述了这些类型的事件是怎样通过Requests For Change (RFC)获得处理和解决的。
发布管理描述了将软件项引入到操作环境中的实践。它描述了活动的实现和发布。
服务台描述了通过集中式能力管理意外和问题的实践。它主要处理像服务类别和意外解决的知识基础这样的关键项目。
ITIL的商业案例

如果一个组织认识到三个商业相关的需要，则ITIL的采用通常是更为有效的。

首先，很多组织在寻找导致基础结构成本容量的操作效率。如果现在我们退后一步评估典型的IT预算，我们经常发现它是由一些离散和非离散的块组成的。离散的支出是那些用于开发新功能以提高竞争优势的支出。非离散预算则覆盖了维持现有水平的支出。Gartner的一项调查显示，中等IT企业大约将其75%到80%的预算放在非离散支出上。经验表明，如果组织采用的操作包含严格的服务管理过程，非离散支出的将近10%到20%可被重定位为离散资金。

其次，上述的实体寻找ITIL实践来降低商业持续性风险。一个近期的客户将从一个供应商处获得的大规模应用程序重新加工。通过这种方式，他们采用RUP和Rational工具来辅助对应用程序开发的复杂度管理。当他们开始过渡活动时，由于操作支持不足，他们很快遇到了重大风险，几乎导致所有的努力失败。从那时起，他们就开始把ITIL作为在未来减轻这些风险的一种方式。

第三，在一些我曾经工作过的公司中，由于IT部门无法实现基本服务水平，终端用户驱动了ITIL的采用。让我们面对这个事实，在一段时间里IT业在很多商业用户中反响很糟糕。我们无法发布，我们花了太长时间或太多钱，而当我们完全发布了应用程序，对性能或支持的期望却没有被实现。我们的一些客户的商业团体转向ITIL以求解决这些问题，因为它提供了一组一致的实践并触及了一些操作组织从未考虑过的领域。

ITIL的采用

十年前ITIL就在欧洲被广泛采用，但是直到最近才在美国开始被采用。尽管ITIL的优势不断显现出来，在很多美国IT专家眼里它仍处于“需要检测和考验”的状态。Gartner 2004年的一项调查显示，58%的被调查人员（CIO，IT操作领导，以及数据中心管理员）对ITIL几乎一无所知。在与一个大金融服务客户的合作中，我第一次真正接触到了ITIL。作为一个负责过程采纳的团队领导，我被要求协助RUP过渡活动，使其顺利完成，以及ITIL 发布管理。那时我意识到了ITIL的成功采用的一个基本障碍。

为了帮助IT领导者从市场上的各种过程中获得价值，我开发了一个商业过程分类策略，该策略是基于企业可应用，且企业采用其的复杂度可以接受的商业过程的。图1显示了这一分析的示例。

接下来，我为过程定义了一个分类策略，把它们分为四类：

最佳实践。对具体任务或明智选择的陈述，如果你是某的特定领域的从业人员。ITIL，PMBOK和CMMI属于这类。
评估，度量，和审核。这些过程通常为某个领域内的组织评估提供成熟度模型。它们在这一度量下陈述最佳实践。CMMI同样符合这一类，来自项目管理 研究院(PMI)的组织项目管理成熟度模型(OPM3)也符合该类。
过程改进。这些集合的活动帮助你分析过程并找到优化它们的效率的方法。这一类的例子包括Six Sigma和Lean。
可执行过程。这一过程不仅就公司应该采取何种类型的实践提供了完整的陈述，还描述了哪些人应该参与实践，他们应该生产什么，工作流和工作流依赖性，以及时间线目标的具体生存周期。RUP是可执行过程的最好例子。
区分这四种过程类型是很关键的，因为在本文中我们的重点是可执行过程，对比其它三种类型的过程它更容易实现并为组织提供了更大价值。

另一个区别是项目相关的过程与操作性过程间的不同。根据PMI，项目是基于目标的，并有清楚的起点和终点（尽管我曾参与的一些项目看起来永远不会结束，但是本文不讨论这点）。操作性过程是那些不断进行，并且在本质上就是持续性的过程。RUP是一个项目相关过程的例子；而ITIL是一个操作性过程的例子。我们将看到，这是一个重要区别，因为这意味着我们必须建立与现有的生存周期模型，比如，RUP生存周期模型，不同的生存周期概念。

当一个组织引进了一组最佳实践，如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基础

对RMC的完整介绍超出了本文的范围，但是在这里我们可以建立一些基本概念。[编者注：如果需要关于RMC的详细介绍，参见文章“IBM Rational Method Composer：关键概念和情境“，也在2006年1月刊中。]

RMC通过方法进行交换。方法是对能够完成的工作以及工作的完成顺序的定义。为了创造一个方法，你必须定义方法内容（何人，何事，何种方法）和过程（何时），但是这些是分离的元素，如图3所示。这里的关键概念是，当你研究过程的现实实现时，对不同项目和公司来说，同性的东西是工件和角色。非共性的是，角色如何共同工作，或者他们应该使用哪些工件。RMC试图通过这一定义最优化可使用性并降低定制化的难度。当我们使用RMC来使ITIL可执行时，我们将从定义方法内容开始，然后定义过程元素。

图3：IBM Rational Method Composer使你能够通过定义方法内容及其过程创造方法

RMC提供了支持方法扩展和定制化的机制。在RPW一般不能用以在组织级上对RUP进行修改的情况下，RMC能够支持项目级的变化，并且实际上还提升了过程管理的水平。对项目经理和管理人员来说，这是不可多得的！这意味着你的工作分解结构和过程定义通过工具取得了同步，并可以通过方法库控制。

组合

到目前为止，你对ITIL，可执行过程，以及RMC有了一个基本的了解。你还应该向你的词汇表中加入了至少十个三字母缩写词(TLA)——这些缩写词对丰富你的履历表是很重要的。现在让我们来看看Noblestar是如何使用RMC来使ITIL可执行的。

我们的任务是帮助一个客户使他们的软件工程和IT操作领域变得严格。在这一任务中过程工程起到了重要作用，并基本形成了本文的基础。

按照我们的工作流，我们的第一步是如何分解ITIL以使任务不那么庞大惊人。明显的选择是按照“ITIL是什么？”一节中讨论的ITIL规范进行分解。正如有分析和设计，实现，测试，等等的RUP规范，ITIL规范同样包括可用性管理, 服务水平管理，等等。这些成为我们的RMC中的ITIL方法内容的建立基础。

我们采用一种迭代的方法来开发内容，并且，基于客户需要，我们从变更管理开始。一个提醒：在建立了一个孤立的ITIL变更管理版本后，团队感到我们实际上可以更多地利用RUP配置和变更管理，而且现在团队已经开始建立组合二者的插件。我们已经准备好开始用角色，工作产品和任务建立包。

原文转自：http://www.ltesting.net