内容


治理和管理企业模型,第 2 部分

通用例行程序

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 治理和管理企业模型,第 2 部分

敬请期待该系列的后续内容。

此内容是该系列的一部分:治理和管理企业模型,第 2 部分

敬请期待该系列的后续内容。

预备知识

在进一步阅读学习之前,您必须首先熟悉本系列文章的第 1 部分:第 1 部分:引言和概念

在本文中,第 2 部分并没有讨论储存库,以为后续的文章的具体例行程序打下概念的基础。本文是以可能使用任意储存库的方式写成的;尽管如此,其他的后续文章将会使用特定的储存库,例如 IBM® Rational® ClearCase® 储存库中的 Unified Change Management (UCM),来处理这些例行程序。

模型管理用例

获得的范例模型(就是从外部来源获得的模型),将会定期的发布带有新特性的版本,以整合到企业模型中。

范例模型发展

这些模型将会经历与您的企业模型相类似的发展。许多版本可能会在模型宣布就绪之前就已经开始了。

在您的网站上,stream代表了可能与图 1 相类似的范例模型。

图 1. 范例模型检查
屏幕截图
屏幕截图

范例模型的每一个新的分布版本,是从前面接受的模型中直接发展而来的。范例模型的关系没有反映查看机理,该机理用于运行模型开发团队中的并行开发过程。与此相反,它只是前面版本的直接继承。

这并不会影响范例模型流程中的父子关系。在图 1 中,版本 1.4 是下一个升级版本,版本 2.3 的父类。但是版本 1.4 却是企业流程,每一个项目流程,每一个操作流程中每一个模型的父类。

这种发展意味着范例模型(它是企业模型的直接父类)可以在任何时候得到变更,理论上是这样。另一层意思是这些新的版本必须成为企业模型,所有项目模型,所有操作模型的新父类

分层模型管理

您可以选择定期的采用模型的最新版本,以利用它的新特性。新特性的一个典型的例子,适合 IBM 行业模型的最新版本,它包含了附件以与 Europe 中的细节新访问规则相协调。潜在可能的是高价值的附件,为模型新版本的价格提供了复杂和困难问题的解决方案。显而易见的是,仔细检查范例模型的新特性,以决定对您的公司高价值的特性,是十分重要的。

宣传这些新的特性到企业版本和任意相关的项目流程,是需要的已完成所有新特性或者变更的集成。当然新特性的采用,需要诸如训练材料,印刷手册以及系统开发活动之类,以支持新采用的范例模型。它只是在模型达到可以发布到企业财产储存库中的检查点时,才会需要,企业财产储存库比如说有 IBM® Rational® Asset Manager。

企业模型管理分解为有三个层次的阶层,它们中的每一个是由企业内的特定角色管理的:

  1. 企业方案,它作为一个整体应用于模型。Enterprise Model Manager 控制了设计为企业层次的变更。
    • 创建新的范例模型:从第三方接受模型(源头之外)
    • 插件带有范例模型的新范例模型:创建企业流程和播种模型。
    • 升级范例模型:从第三方接受升级的模型。
    • 从企业模型中播种项目模型:创建项目流程并将它们发布到企业模型的最新版本。
    • 获取项目模型到企业模型:从项目到企业模型获取变更。
    • 对项目宣布企业模型:对所有项目宣布新的企业模型特性和变更。
    • 定期的验证模型(根据您公司的政策)。
    • 定期的发布并推荐基线模型(根据您的本地政策)。
  1. 项目方案,它适用于建模团队中的个人项目。一个 Project Model Manager 控制任意一个项目中的方案,而 Enterprise Model Manager 管理项目作为一个组。
    • 创建操作流程并发布模型。
    • 定期的验证模型(根据本度政策)。
    • 定期的宣布和推荐基线模型(根据本地政策)。
  1. 执行方案,使用和发展模型来适用于个人。每一个私人建模者(例如,一个商业分析师或者开发员)处理这些方案。本地的 Project Model Manager 管理项目模型的总体发展。
    • 根据项目模型管理员设置的任务,来执行模型的升级。
    • 不论何时推荐新的基线时,发布项目模型到开发流程中。
    • 不论何时任务完成时都会对项目流程获取变更。

图 2 显示了公司模型阶层所有层次的所有方案。接下来的章节描述了具体的每一个贴过标签的操作。

图 2. 所有模型变更方案
屏幕截图
屏幕截图

每一个方案都涉及到了企业内的工作流程。每一个流程可以被复制很多次,这样有很多同时操作的项目以及数以百计的操作工作。企业建模的潜在规模是严格例行程序和管理的驱动力。

模型管理

在企业层次里,变更可以从获得的范例模型发布,并从项目模型获取。范例模型的新版本的来临,可能会触发新特性的广泛使用,因此影响到所有的储存库模型。与之类似的是,重要项目模型的采用可能会激发所有其他项目间相同类型的最终发布。

企业分层方案

范例模型从硬盘上获得,或者下载而来。Enterprise Model Manager 和储存库管理员协作以执行这些任务:

  • 创建一个储存库
  • 为范例模型创建一个流程
  • 向流程添加范例模型

传播新的范例模型

向需要 Enterprise Model Manager 的创建流程添加范例模型拥有本地工作区的模型。模型可以从文件系统中导入到工作区,例如从原始的分布 CD 中导入。如果它们以 RAS 格式(可再用资源规格说明)进行分布,那么导入它们就需要运行 RAS Import 命令了,并导入到 RAS文件中。否则,它们可能需要提取出压缩文件,或者文件夹可能会从 CD 或者下载位置直接进行访问。

当模型在本地工作区中,将它们整合到一个流程中取决于特定的存储库。但是,它们中的大多数都拥有提供 share命令的插件。

 share命令位于团队下拉菜单的下面,它可以在 Eclipse 项目层次上进行访问。最好同时选择所有的模型项目,以对它们都执行 share操作。

在模型移动(共享)到存储库中之后,范例模型现在就处在版本的控制之下了,模型就需要规范的检出和检入例行程序了。

传播带有范例模型的新企业 

第 2 个流程得以创建以保持企业模型,它来自范例模型。为了维持正确的继承关系(父子关系),企业模型位于范例模型流程的 child流程中,如图 3 所示。该子流程的创建需要使用特定存储库的合适分支命令。

图 3. 传播企业模型
屏幕截图
屏幕截图

接下来,通过使用合适的同步化命令,范例模型会传播到企业流程中。在这种情况下,宣传创建了模型产品的新版本,就像物理拷贝或者虚拟的拷贝(可能只有标签)。在一些存储库中,在产品实际上被变更之前没有发生任何有意义的事情。

关键点在于企业流程现在在逻辑上是范例流程的子类,以及所有项目流程的父类。在企业流程的结尾获取特性;特性从来都不会传播到范例流程中。

升级范例流程

当得到新的范例模型时,它们必须被整合到模型存储库中,这样它们在逻辑上都来自前面产生的范例模型。这一点很重要,因为为企业模型维持合适的宗族关系是必要的。

如图 4 所示,范例模型会整合到流程中以作为已存在产品的新版本,这就可以有效的将前面的范例模型替换为新的内容。向存储库添加最新模型中新的产品,在最新模型中不再显示的任何产品,都会从存储库中删除掉。

图 4. 范例模型升级过程
屏幕截图
屏幕截图

向企业模型推广新的范例模型

向存储库有效的添加新的范例模型,会破坏继承关系,这种关系必须得到恢复以向企业模型传播新的变更。范例模型的版本与 IBM 模型流程有关,如前面的图 1 所示。

图 1(重复). 范例模型查看
屏幕截图
屏幕截图

但是存储库继承关系仍然保持如图 5 所示的早期版本那样。

图 5. 在重新设定关系之前的企业模型继承关系
Screen capture
Screen capture

但是,存储库继承关系树中的父类需要影响到新的继承关系树,如图 6 所示。

图 6. 升级父类关系之后的企业模型关系
屏幕截图
屏幕截图

显而易见的是,如果企业模型只是简单的从新的 IBM 模型中得到重新传播,那么从版本 1.1 到版本 1.4 所做的变更就会全部丢失。解决这个问题的方案就是将新特性从范例模型传播到企业模型中,合并范例流程的变更和企业流程的变更,到企业流程的最终版本中。

这个传播有两个目的:

  • 重新定义企业模型的父类(“re-parenting”)到范例模型的新版本中
  • 从范例模型中获取新的和变更后的特性到企业模型中

通过建立新的范例模型作为企业模型的基线,来开始重设关系的操作,使用存储库的同步化机理可以做到这一点。使用的操作特定于任意一个存储库以及使用中的分支方案。

在这里,存储库探测到父类(范例)模型集合中的新版本时,并启动三方合并以合并企业模型中的每一个产品。

图 7 显示了合并过程是什么样的。

图 7. 为传播和重设关系合并操作
屏幕截图
屏幕截图

该合并方案是倒转通常与经典的平行开发三方合并模式相关联的操作。这个经典的例子试着以获取新变更的视角来查看。这就是说,当前的本地版本一般会 冲入父集成流程中。

另一方面,一个传播三方合并拥有 冲入变更的意图。普通的父类和远方的产品都位于严格意义上的同一位置:都位于父类流程处。本地工作区版本是另一个变更贡献者,一般位于本地工作区处。

再一次,为了清晰的表达:新的模型产品会直接存储到范例模型中,对于在企业流程中所做的变更来说,被当作平行系列的变更,直到最后一次范例模型得到升级和传播。这使得最后一次升级的范例模型(版本 1.4)成为父类。新存储的版本(如 2.3 所示)成为远程的版本。最后一次检出的版本(企业流程上的 1.4)成为会接受变更并检回自版本 1.5的本地版本。

这种微妙的差异并不以任意重要的方式来变更基本的合并机理。但是为宣传或者住入而必须选择的新的或者变更的特性,是十分关键的。每一个显现的差异必须得到检查,或者被接受或者被拒绝。冲突必须在很大的深度范围内得到检查和解决,尤其是在范例模型方面

项目分层方案

一个或者多个商业目标会定期的激发创建新项目,并将该项目宣布为企业模型流程的子流程,由企业模型管理员和存储库管理员来合作创建该流程。从企业模型那里传播项目模型。

如图 8 所示,新的项目在逻辑上来自企业模型,并在现在熟悉的传播操作中非常流行。

图 8. 传播项目流程
屏幕截图
屏幕截图

忍耐这种重复,但是:企业模型使用与所有其他传播操作相类似的机理,来 传播到项目流程中。

从企业模型中获取项目模型

当 Enterprise Model Manager 和 Project Model Manager 达成一致从项目模型获取新的和变更的特性时,它们中的一个(取决于本地政策)通过使用合适的存储库机理,来开始获取操作。

在获取期间,变更操作就是从子流程到父流程的变更,这与经典的平行开发交付机理相平行。这就是说,模型管理员将变更从项目流程移动到企业流程中(以同样的方式操作人将变更从私人的开发流程,带入到项目流程中,在稍后的段落中会介绍一个方案)。

如果没有平行变更被检测到的话,那么存储库的同步化机理会重写已存在的模型。但是,在更加典型的情况下,会有平行变更被检测到。在项目流程通过传播操作与企业同步化之后,当其他人的变更交付到企业流程时,这就会发生了。如上所述,一个合适特性的存储库将会检测到并行变更,IBM® Rational® Software Architect 会启动三方合并获取两方的变更到最终的版本中。

获取操作如图 9 所示。

图 9. 获取项目变更到企业流程中
屏幕截图
屏幕截图

在合并操作期间,Enterprise Model Manager 对于处理在企业模型和项目模型之间的差异时,有一些选择。在获取操作期间有一些因素会影响所做的选择:

  • 在最新的企业模型和最新的项目模型之间,可能会有冲突性的变更发生。当两个项目在没有协调的情况下变更同一个区域的模型时,就会产生这一个问题。因为企业模型已经接受了第一系列的变更,所以再来的变更就必须与已经接受的变更相比较,这种关于建模特性或者执行的冲突必须得到解决(在比较工具中完成,例如 Rational Software Architect 中包含的)。
  • 在企业层次可能会没有变更。在这种情况下,模型管理员可以自由的接受来自项目模型的变更,而无需犹豫,只有满足一个因素即可(例如,合并和范例建模标准)。
  • 在项目层次可能会有不能接受的变更。模型管理员可能选择拒绝这些确实不合适的变更。这就迫使项目模型的最终协调,尽管政策会决定项目模型可能会在企业模型内持续多长时间。当然项目模型管理员选择重构未接受的模型变更,删除它,或者为稍后再次的获取拒绝变更。

获取操作会执行一半合并项目流程的工作。它获取项目变更到企业流程中。但是来自其他项目的什么变更将会处于企业流程中?项目模型是怎样升级这些变更的(意思:与企业模型的最新推荐版本保持同步化)?这就需要另一步:从企业模型中传播变更到项目模型中。

传播企业模型变更到项目流程中

在前面描述的原因之下企业模型得到升级之后,企业模型管理员将会最终传播最新的特性到项目中。时间由本地政策决定。

图 10 显示了项目流程的全部协调以及企业流程。

图 10. 传播企业变更到项目流程
屏幕截图
屏幕截图

这个图表显示了与项目和企业流程相关的一些关键点。

  • 传播可以从任何地方开始。新项目的创建一般都从企业模型的最新版本开始。在这种条件下,项目 1 从版本 1.4 开始,项目 2 以及 3 从企业模型的版本 1.5 开始。
  • 版本号码不需要从一个流程到一个流程保持一致。实际上,存储库通常从版本 1 来启动一个项目流程。图 10 中的图示在新流程的开始保持一致,以让传播更加的清晰。但是所有的流程可以只是简单的从 1 开始。存储库根据它偏好的规则分配一个固定的号码。
  • 每一个获取和传播都有可能获取一次合并。这是团队并行开发的本质所在。这就是使用和工业强度模型管理相联合的工业强度存储库,以及合并那些可以在 ClearCase 和 Rational Software Architect 中找到的功能的全部。

变化的项目

保持一个项目在不断的变化以及在未来的传播过程中将其升级,是十分可以接受的,但是一个项目允许对企业模型的最新推荐版本操作的时间越长,不协调变更的风险就会越大,因为项目随着时间的增长会变得四分五裂。

一个特性丰富的企业存储库对于没有同步化的传播没有复制的问题,也不会获取项目和企业模型之间的循环,循环如图 11 所示。

图 11. 流程协调循环
屏幕截图
屏幕截图

本例中的“传播到项目”相互之间或者与企业配合的都不是很好。每一个项目都会根据它自己的需要,获取自它自己的方案并传播到它。只要它们不断的传播,它们就可以避免掉入保持异步太长时间(变黑)的陷阱:由于太多的冲突发生复杂性出现。

从企业项目管理员的角度来看,异步化项目的主要困难在于,它不能在任何时间任何点轻易的获得企业模型总体状态的信息。本地的政策必须根据公司容对于更广同步化间隔的容忍度来设置。每一个例行程序和检查点都有一个明确的成本,主要是生产效率。但是走的更远,生产效率就会被增长的重复劳动所阻挡。在这里企业必须找到一种更好的中介。

回到传播 操作:这是从父流程到一个或者多个子流程传播的又一个范例。这就是说,一个简单的流程到流程同步化会延伸通常的防止数据丢失的三方合并。结果就是每一个参与的项目流程都包含了来自企业流程的新特性。但是,有一些问题可能会阻止完全的同步化,使得项目流程随着企业流程而变化:

  • 企业模型可能并不会接受项目模型变更。在这种情况下,项目模型管理员可能想要重复,或者改进它们以让它们进一步接受到企业模型流程中。
  • 项目模型管理员可能需要时间来达到一个目标或者时间期限,可能不能当前开发循环中的传播问题。
  • 项目模型管理员可能需要更多的时间,来对模型作出变更,以消除前面放弃或者部分接受的获取期间发生的冲突。

在一个理想的世界内,获取可能会将所有的项目模型变更带入企业模型中,然后企业模型就会覆盖最近获取的项目模型。新的特性会立即向所有其他项目模型传播,此时企业中的所有模型将会达到一种完美的排列。

但是既然理想的世界并不存在,所以在本地操作和习惯的基础之上,允许项目变量的存在以及建立平衡重复劳动的生产效率就是必要的了(例如,覆盖模型部分责任的普遍性)。

执行者分层方案

执行者的模型管理被分为基于角色的两个部分:

  • 业务分析员
  • 软件服务和数据分析员或者设计师

业务分析员通常收到存储库系统方面的训练,并需要隔离于存储库操作,获取和传播循环之外。项目模型管理员可能期望代表这种没有多少技术含量来执行这些例行程序。

另一方面,软件服务和数据设计和分析,通常是由那些暴露于存储库和并行开发模式下的建模者来执行。

本段解释了要么是项目模型管理员要么是数据建模人员执行的存储库操作。

从项目模型传播执行模型

模式的本质在于它促进了成功例行程序的重复。来自项目流程的新执行流程的传播也不是例外。它使用熟悉的传播项目模型到一个新创建执行者的开发流程。

在项目模型管理员创建后续流程以作为业务分析员使用的代理时,注意这个方案并不会变更。对于每一个处理项目模型的个人来说,必须要有一个私人流程。这允许存储库和项目管理员来追踪模型每一个拷贝的状态。

获取到项目模型的执行者模型

这个获取在 本质上与在前面名为“Harvest project models to enterprise models”的段落中描述的获取操作相类似。唯一的变量是由政策处理的(见于本系列文章第 1 部分中关于管理部分的描述):计时,角色,推与拉。这些就是抉择 :

  • 私人建模者控制的传播和获取操作。这拥有从每一个其他人员的安排中退耦团队成员的优势。但是,它允许更少纪律性的人员 忽略长时间,这使得合并和重复变得更加困难。注意这里的风险,与前面提到过的关于项目到企业协调问题的相似性。
  • 循环是阶段性和强制性的 。每一天(或者每一周),所有的执行者都希望获取变更到集成流程中,在此之后的每一个早晨,他们希望传播完全升级的项目模型到他们的私人开发流程中。这个工作流程的优势在于,项目模型会一直保持更新,而且所有的执行者都会相互之间保持同步化。这在过程的早期就能得到解决,并随着时间的增长而越发重要。它的缺点在于,建模者可能不得不提前进行变更,这可能会导致一些重复劳动甚至模型破坏。
  • 循环是阶段性和可选择的。一个私人执行者可以执行一次获取或者宣传,以完成整个的工作,而不需要与来自其他执行者所做的变更协调未完成的工作。人们期望这种状况要尽可能的少,因此这种选项处理前面选项的主要负面结果,并且是大多数公司的理想选择。

传播项目模型变更到执行者流程

这种执行者的传播通常遵循周期性的获取循环,并被设计成完成所有执行者的同步化。

一个执行者可能会选择传播每一天以与其他执行者的工作保持同步化。这就允许一个执行者处理模型的最新版本,并享有降低合并频率的显著利益,特别是复杂合并的频率导致冲突时有发生时更是这样。

实际的机理与前面讨论过的企业到项目传播相类似。

代理的执行者模型管理

在公司内业务分析员和其他更少技术性人员组成了一个建模团队,一个代理管理机制可以帮助维持高度的控制性,以允许这些团队的成员只关注自己领域内的建模任务。项目模型管理员可能希望执行自己的模型管理任务,如图 12 所示。

图 12. 代理的模型管理
屏幕截图
屏幕截图

项目模型管理员通常会执行共享网络驱动器上的工作区,并执行本地政策定义的周期性的获取和宣传操作。对于实际的获取和宣传例行程序就不会再有什么变更了。

通过提供一个指向可以在合适工具中打开的工作区,项目模型管理员可以与每一个业务分析员相协调。当变更完成并为获取到项目做好准备时,业务分析员会指示项目建模管理员(通过基于活动的管理系统,例如 UCM-enabled ClearCase 或者 IBM® Rational® ClearQuest®)。

接下来做什么

这些例行程序使您能够全面理解建模团队并行开发时所需的严格基础性理解。阅读本系列的后续文章以展开例行程序覆盖 Rational ClearCase UCM 和 IBM® Rational® Team Concert。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=417987
ArticleTitle=治理和管理企业模型,第 2 部分: 通用例行程序
publish-date=08032009