内容


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

引言和概念

Comments

系列内容:

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

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

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

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

前言

本文概述了管理开发企业模型的推荐方法。该模型处在不断发展中,因为它们是作为模型驱动开发使用和重用的基础。这种方法提供了与获得性的范例模型协调工作的指南和规程,范例模型例如 IBM®Industry Models(例如,IFW Banking 和 IAA Insurance 模型)。

尽管这些规程最初是作为企业模型管理的完整工作流程,但是它们还可以用于并行开发或者含有模型的工作的任何情况下,这些模型处于主动开发或者用于主动开发并且一开始就打算保持模型的完整性。

本文定义了特定的功能性角色,以更清晰的分配责任、意图和目的。例如模型管理员和执行者都分配有角色,就算在不同的时间内由同一个人扮演这两个角色也是可能的,我们仍然保留这两个角色。这必要的。因为这可以确保这些角色各自独立发挥作用。例如,模型管理员角色也许是由“戴着模型管理员的帽子”的人扮演的,但是这个人应该是被认为是最适合模型的人。

更为重要的是,这些规程可以作为本地管理文化采取的行动指南。这些指南并不是腐化不变的。但是,您需要意识到,偏离相对规范规程而向不规范的方向发展,会增加对公司财富,例如企业模型伤害的风险。

引言

本系列文章中描述的方法,用于支持使用模型的企业或者企业的一部分,以帮助它们描述和控制它们的发展。这些规程特别处理了特定使用环境下维持模型完整性的需求,这就是说,控制由多个团队和执行者,对模型语义、设计点和结构所做的并发更改。它们可能是企业开发的模型,或者企业购买的模型的框架,例如 IBM 行业模型。IBM 行业模型是作为模型驱动开发使用和重用基础的企业规模模型的具体范例。本章节的剩余内容介绍了这些模型。

IBM 行业企业模型收集了一系列相关的模型,为一些行业,例如银行业(IFW)和保险业(IAA),的业务、软件(服务)、数据领域和程序或者服务型的方案,处理其分析和设计的关键问题。本文特别感兴趣的是 IFW 和 IAA Process 以及 Integration Models,它们作为 IBM® Rational® Software Architect 和 IBM® Rational® Software Modeler UML 2 模型交付(就是 Unified Modeling Language 2.0)。它们可用于创建企业进程可再用分析和设计描述,并支持软件服务和数据(见于图 1)。

图 1. IFW 模型构架
图形
图形

IBM Industry Models 并没有提供一个预定义的方案,注意到这一点很重要。相反,它们提供的是对平台独立的模型,它抽象出了任何一个问题领域内任何单个公司的具体情况。模型提供了蓝图和标准,在此基础上,可以构建特定的进程和服务。

IBM Industry Models 和企业建模的主要目标,是鼓励重用稳定的定义,相关的工件,以及相关的实施,例如软件服务。这部分回到了“为什么企业建模以及它的管理很重要?”这个问题。企业建模是建立企业服务型的构架(SOA),模型驱动开发(MDD)以及模型驱动构架(MDA)的基础。

对企业模型发展,而不是革命,对于模型管理极端重要,因为建模工具,例如 Rational Software Architect,可以在模型的不同版本之间,执行精确的模型比较-合并操作。当合并新的模型或者特性到企业模型中时,模型差异性可以被个人或者集体接受或者拒绝。

这种基本的模型管理机理,同样允许模型变更向下进行 传播,并 获取 上传到对处理特定业务目标以及有效服务企业模型变更负责的项目。因此项目可以并发工作,并与其他工作人员的日常变更相隔离,而不需要进行费力的协调。这种机理保护了每一个项目以及每一个个人的生产效率,同时,确保他们都对企业模型的控制式发展做出贡献。

尽管 IBM Industry Models 在本系列文章的前两步并没有得到直接引用,但是这系列文章中的信息,与那些想要执行并行模型驱动开发的企业的管理工作直接相关。

模型管理的基础

模型管理是一个常见的与一些关键关注点相关的词语,每一个关注点都有它们自己的规程和进程:

  • 治理:模型管理发生的环境,包括一系列的政策制定,其他的关注点是,谁来管理,管理什么,什么时候管理,怎样管理、评价和控制物理资源(模型),以及可能对它们所做的变更(也可能不会)。关注的还有出于统计和管理的目的,为所有变更维持历史记录的必要性。
  • 持久性:将企业资源(模型)存储在一个安全,可访问并且可靠的工具内。
  • 版本化追踪并控制所有的变更作为模型连续的序列,或者版本。
  • 发布:至少有两类与之相关的发布:
    • 发布模型作为可再用的企业资源:使其他人也能够在开发周期的正确时间,使用模型的正确版本。与配置管理储存库相连的可再用资源储存库,确实能够加强这一点。一个范例便是,向处于 IBM® Rational® ClearCase® 配置管理控制下 Rational Software Architect 模型的 IBM® Rational® Asset Manager ,提交一个模型的版本。
    • Web 发布:使模型作为一系列网页以只读形式访问。
  • 比较和合并比较,检查,并可能合并相同模型两个版本之间的差异;接受或者拒绝私人版本或者公共版本之间的变更。被比较的两个版本模型的公共起源,也应该得到比较,注意到这一点非常重要,因为它提供了足够的环境以解决冲突。关于它的原因在 Comparing and merging UML models in IBM Rational Software Architect: Part 2. Merging models using "compare with each other" 中有所描述,文章的作者是 Kim Letkeman。
  • 报告:通过使用一般的浏览器界面,使模型作为替换方案可以使用。这也涉及到了模型问题的报告,例如 UML 2 违反(也叫做模型验证),并在安全性程序得到破坏时报告安全性违反。例如,当模型管理员在不经过允许的条件下,将变更引入企业模型,报告机制检测到了这项破坏规则的操作,就会发生这种情况。这种类型的报告适合更加一般的管理区域。

尽管这篇文章处理了所有这些关注点,但是它主要关注的,是模型管理和版本控制,因为它们定义了成功管理使用 IBM 行业,或者一切规模企业模型所需的规程。

团队开发简介

本章节回答了或至少部分回到了一个问题:“为什么所有这些模型管理这是必要的?”。

所有非平凡的软件,都是由项目生命周期期间并发工作的建模人员、分析员和开发员组成的开发团队开发和交付的。团队需要意识到一个简单的事实:软件开发是非线性发展的。很显然可以由一个或者两个人员开发的程序(例如,您在学校所写的程序),很少需要管理或者协调,因为它没有什么复杂性。

但是,构件的数量翻倍,那么复杂性的增长不止翻倍,因为每一个构件的内在复杂性与其他构件的复杂性联系在一起,使得总体的复杂性爆炸性增长。伴随着的还有偶然式的复杂性:该复杂性起源于执行者的选择而不是内在的问题。搜索“魔术弹”的操作会继续下去,不要感到惊讶。

不能找到魔术弹,那么对复杂性问题最实用和最佳的解决方案,就是在实施之前对业务环境和软件服务建模,以最大化业务相关性,消减过大的复杂性,并尽可能的最大化重用。在这里,IBM Industry Models 是一个极大的例外,因为他们将模型与最佳实践结合在一起,这部分工作在行业主导型公司内持续了二十多年。

并行开发

团队成员的工作区域与其他人必须隔离开来,以取得和维持高层次的生产效率。团队成员之间过多的交流和过多的协调,可以很容易的带来开发的停滞。

但是,如图 2 所示,必须要有一定程度的变更协调,这样并行更新才会被检查到,内容才能得以顺利合并,以避免丢失更改集,或者破坏最终的工件。

图 2. 未管理的并行开发,数据丢失风险
图形
图形

接下来的章节将会讨论,检测和协调并行开发的通用方法。

幸运

当工具并不支持团队工作或者并行开发时,或者规程是ad hoc时,执行者希望协调使用中工具和储存库内容外部的所有变更。稍后将会提到,当只涉及到两个人时,这很容易实现,只需管理一条交流路径。但是,随着团队规模的增长,交流路径也在非线性的增长。达到 5 个团队成员的规模时,交流路径的数量已经剧烈的增长到了 10。如果再加 2 个团队成员,那么团队成员之间的交流路径将会达到 21,是刚才的两倍多!

关键结论:
“幸运”并不会随着团队规模的增加而保持住。随着团队规模的增加,就需要更加规范的进程了。

手动进程s

可以创建并严格遵循规范的手动规程和方法,以防止对模型整体性做出伤害。创建模型的可编辑版本时,一般会进行严格的访问控制,并在模型使用和开发的每一个阶段都进行严格的管理。例如,在周一早上向所有的建模人员发送模型的拷贝,然后在周五的下午收集并合并所有的变更。

在这些规则下,自我治理是不允许的,模型在一般情况下都是很安全的。生成效率会有间歇式的停止,因为在工作流程的每一点上都会有管理的干预,但是当考虑到幸运方法内在的风险,这点还是可以接受的。注意使用手动进程所需的努力和进程的层次,要比其他的高出很多。您还需要注意,“大爆炸”式的合并造成巨大的风险,因为如此多的变更积累起来,使得重叠的变更就是一个实际性的不确定性因素。不断的将私人执行者变更整合到主要的项目模型中,并行开发从中获益匪浅,因为两个原因:

  • 执行者正在处理的不止一个模型的当前版本,这就有助于降低重复编码和重复劳动。
  • 冲突更少的发生了,而且,当发生冲突时,需要合并的变更规模更小,风险更小。

关键结论:
手动规程并不支持在不增长风险和工作量的前提下,频繁的合并。

自动化

管理并行开发并控制资源,而没有或者很少受到执行者或者管理层干预的工具,能够提供最高级别的管理性和安全性,同时还为团队保持一定程度的生产效率。因为现在工具执行了所有需要的并行开发检测工作,并在协调合并并行版本的同时,追踪结果,在每一步为额外的进程使用工具就不再需要了。工件所面临的风险降低至零,因为前面的版本,在严重进程错误发生时都是可以恢复的。

执行者可以选择什么时候将其他人的工作整合到他们的工作区,以及什么时候他们可以将自己的变更整合到项目模型中。这种自由促进了高生产效率的发展,进而增加了程序的质量(这一点已经由 Tom DeMarco 和 Tim Lister 所做的一些研究证明)。

关键结论:
自动化团队开发可以产生高层次的生产效率,并保证模型置于控制下的发展。执行者能够关注概念性和区域性的建模层次,并使用工具来为模型工件的管理,和变更的协调做出很大的贡献。

定义和词汇

在继续之前,需要定义一些术语,以便文章的剩余部分使用。没有这些术语,解释就会异常困难。

  • 模型层:图 3 显示了外部获得的典型模型层,并传播到企业内的其他层中。注意层代表了开发中的模型。这些关系存在于特定的时间,并且可以更改(例如:项目起始时以及最终完成时)。
图 3. 企业开发的模型的层级结构
范例 > 企业 > 项目模型
范例 > 企业 > 项目模型
  • 范例模型:该层可以包含任意系列的外部获得的范例模型。一个例子便是银行业(IFW)和保险业(IAA)的 IBM Industry Models。外部获取的意思可以是从团队之外的第三方或者开发团队购买的。关键点在于这些模型可以在新的版本中重新获得。该层与没有任何变更到来的模型很相似。定期性的更新包含的变更,一般只会向衍生模型的客户提供高的价值。
  • 企业模型:该层包含的模型版本,被认为是企业内模型的主要集合。它们来自外部获取的范例模型;因此,它们被认为是这些模型的子代。注意企业模型存在于不同的层也是可能的。当需要集中企业模型而不需要维护一个或者多个部门、商业单位或者地区之间永久性的差异性时,这种情况就会出现。应该将这种情况看做工件层次上继承性的一种形式。
  • 项目模型:该层包含了源自企业模型的模型,并含有暂时性的差异。它们的存在为模型的发展提供了一个平台,该模型是特定系列业务需求需要的,或者项目需要完成的目标。所有这些变更会成为企业模型的一部分,或者在某个时段从项目模型中删除。这意味着分析和设计所做的选择,对一个特定的项目可能是最好的,该项目会边缘化它们在企业内的再用性。这就导致这些类型模型和衍生工件的泛滥,反过来,又削弱了企业模型和资源的基本价值,特别是 SOA 更是这样。企业模型和项目模型之间的互动驱动了本文中记录的许多规程。

通用词汇

  • 流:模型文件的逻辑组。每一个单独系列的 IBM 模型、企业模型和项目模型都有一个流,所谓的流源自父流,层级结构中任何当前流之上的流都叫起始流。主要的流叫做集成流,它指示从上输入或者从下输入都有集成点。执行者的流叫做开发流,它指示它们的任务就是每天进行开发和建模。
  • 储存库:单个含有模型的一个或者多个流的数据库。
  • 获取:从后代模型中获取变更的行为。两个经典的例子是:
    • 在项目集成流中获取执行者的变更。
    • 在企业的集成流中获取项目的变更。

是由后代流管理员 来执行变更(向上推进变更),还是由起始流管理员(向上拉动变更)来执行变更,这是一个政策决定。

  • 传播:将变更传至后代流的操作。三个经典的例子是:
    • 从获取范例模型的更新中传播新特性
    • 从一个项目向其他所有项目传播获取的变更
    • 向所有项目执行者传播其他的执行者变更

是由起始流管理员来执行变更(向下推进变更),还是由后代流管理员来执行变更,(向下拉动变更),也是一个政策决定。什么时候每一个项目必须遵循企业模型,以及项目与企业保持差异性可以维持多长时间,这也是一个政策决定。项目到支持者关系也需作出相同的选择决定。

角色

每一个模型工件都必须当做关键资源或者公司财富来 管理,以确保它的完整性。但是,既然项目的商业目标可能与企业目标发生冲突,所以清晰的定义模型管理角色并将它们相互隔开就是必要的了。

当需要作出影响到特定模型的决定时,必须要扮演特定的角色。例如,在考虑是否将项目的变更引入到企业模型中时,需要扮演企业模型管理员的角色,以合适的评价 企业的目标、需要相关的变更的影响和价值,并比较私人项目的目标、需求和关注。

接下来的角色在文章的整个后半部分都有引用:

  • 执行者::一个项目中的私人建模人员,业务分析员,或者开发员。引用执行日常处理开发工件,例如模型或者源代码工作的角色,有三种精确的方式。这些角色创建项目模型中的变更,并最终将这些变更获取到项目模型中,然后输入到企业层次的模型中。如果模型管理员需要的话,这些变更可以进一步传播到其他所有的项目模型中。当术语 modeler 可以解释为程序本身的引用时,会用到 Practitioner
  • 模型管理员:对特定系列的模型负责的角色,通常位于一个概念性的中。该角色验证从上或者从下而来变更的质量和价值,以确保执行者遵循本地政策。
  • 企业模型管理员:该角色为企业模型的发展和管理负责,包括通过更新至获取的范例模型,来接受或拒绝项目特定的变更,以及引入到企业的变更。
  • 项目模型管理员:项目模型管理员根据整个项目中的业务目标,对项目特定系列的模型的发展和管理负责。该角色与企业模型管理员以及其他潜在的项目模型管理员协作,以根据本地政策建立或者协调变更的时间。该角色需要确保项目变更在企业层次上可用以让项目平稳的运行。允许执行已经知道在企业层次上不能接受的变更,就是接受无价值的工作,因为项目最终会不得不放弃这些变更。
  • 储存库管理员:该角色对储存库的物理管理负责,并且可以与其他任意的角色联合工作。

每一个项目管理角色相互之间的差异性都很大。请注意,一个人可以扮演多个角色,一个角色也可以由多个人来扮演,明白这点很重要。例如,一个领域的架构需要独立工作,以控制该领域内的整体性(例如,企业模型管理员对“产品”领域负责)。但是也许一个角色也许会与一群作为“企业模型管理员”的人(一系列的领域架构,每一位专家都对企业模型的特定子集或者某个领域负责)集体的工作,以确保企业模型中所有领域的稳定发展和完整性。

对模型差异性的简介

本章节回答了“怎样比较和合并模型?”这个问题。

一般来说,一个模型由语义性的和计数性的信息组成。语义性的信息定义了模型给定部分的意义。例如,一个描述了现实世界中的一个物理对象。角色,也是这样,尽管一个角色也许是一个执行进程中特定作用的人或者机器。在他们得到记录之后,这些语义元素对相同领域内的任意模型,都有潜在的作用。

计数,另一方面,计数描述了一个类或者角色是怎样在图表中表示的。一般来说,它可以描述:

  • 样式信息,例如字体,字体颜色,线条颜色以及等等
  • 位置信息,例如图表中的xy坐标
  • 使用 Edges 的元素之间的关系和联系
  • 注释,文本,几何形状以及其他的图表位置注释

语义项也许会出现在一系列的图表中,这样符号对程序就没有什么具体的意义了。尽管如此,合理的使用它,可以显著的提高语义元素之间关系的清晰度。

每一个更改都会产生差异性,该更改是对比较中模型的一个或者两个版本中的元素做出的。最小化生成的差异性,对于降低模型管理功能必须评价的差异性的数量以确保模型的完整性,非常重要。例如,毫无缘由的在图表中移动元素(只是为了查看)一般来说,是一个坏主意,因为每移动一次元素,不管它多么轻微,都会造成差异,长此以往,模型就会进入到另一个层次。

注意:
环境中另一个经常使用的术语是 delta,它描述了模型比较-合并编辑器中可见的差异性。

标记

也许现在您想知道,自动模型变更管理工具中的模型比较子系统,是怎样相互之间匹配对象,这样我们就不会看到大量错误的差异性了?这是通过使用标记来实现的。每一个元素,不管它是语义性的还是记数性的,都会在我们创建它时被分配一个标识符(ID)。这个 ID 是不能更改的,这就是说,它从来不能变化。

因此,向一个类添加属性或者操作,将总是会显示为向合适的类“添加 deltas ”,因为在模型的两代中类都是使用同一个标识符。但是,如果一个类被删除后重新添加回来,或者得到存储,对执行者来说好像没有发生什么改变,但是实际上该操作创建了类的新版本,该类对于老的类来说呈现“删除”差异,对于新类呈现“添加”差异。换句话来说,它们不是同一元素,就算它们看起来像是,并且拥有相同的标识符也不行。

在删除和添加时进行的比较,总是显示出删除和添加操作的差异性,这就掩盖了稍后对它们内容的更改,因为对包含数据的变更只与拥有相同标识符的元素相关。这个问题再次强调了,模型按照传统的方式发展是多么的重要。偶然的删除一个对象,然后用相似的对象来替换它,将会导致企业模型代与代之间不能接受的多余的差异。

安全性

企业模型的安全性体现为两种方式:监控的和加强的。

对于监控的安全性,模型都位于同一存储库中,模型管理员使用报告和查询来决定是否有访问入侵发生。例如,一些软件配置管理存储库通过特定的建模人员来追踪每一次变更,因此评审规则违反的具体信息,接受或者拒绝活动的变更,就变得更加容易。

而且,通过定义和应用管理模型的政策,安全性得到了提高。这些政策包括项目可以保持多长时间的差异性,项目多久与企业模型协调一次,谁来决定向企业模型引入什么变更,以及由谁来执行项目或者执行者层次的实际获取和传播操作。

加强的安全性,另一方面,通过将企业模型与项目模型隔离开来,以及将项目模型相互隔离开来,防止未授权的人作出变更。它为每一个人提供了单独的权限。因此,管理保留了对访问模型特定集合的控制权,这就阻止了潜在的安全性入侵。这项收益的成本就是非常高的进程总开销,它会抵消集成进程和自动化进程所带来的收益。

本文只关注监控的安全性规程

模型起始和模型变更贡献源的类型

当并行开发需要将两个系列的变更合并为模型的单个最终版本时,就需要模型起始以进行比较了。工具会将每一个变更的模型与它们的共同起始相比较,而不是比较两个变更了的模型。然后该工具会比较两个 delta 集合,以创建冲突的列表,这些冲突必须通过接受一个或者其他到来的变更来得到解决。

模型比较和合并中模型起始的使用,是我们必须理解的非常重要的一种进程。理解它是很必要的,因为我们的目标是让模型在团队环境下发展,某个版本的模型成为多个新版本或者代的合伙或者起始。两个或者更多的建模人员必须定期的将存储库和工作环境保持同步化,这一般会在工作循环开始的时候执行(每日执行,或者每周执行,一般由政策来决定)。当第二个或者任何随后系列的变更传回至存储库时,并发变更会自动检测到,合并操作随后就会启动。

存储库工具应该与 Rational Software Architect 相协调,以载入三个关键的模型版本,并为三个贡献源的每一个提供一个清晰的变更列表:

  • 起始:也叫做公共起始,有时也叫做基准模型,这是并行开发模型可以追溯的宗系关系中最近的一个起始。
  • 远程的:最后一个变更的模型成功的提交到了存储库中。远程已经有了所有来自合并的公共起始的并发版本,这样唯一的需求就是将最新远程版本的变更与本地版本的变更集合合并起来,以创建模型的最新版。
  • 本地:工作区中模型的版本,当前被提交的。
  • 合并:合并模型等同于公共的起始模型加上从远程模型接受的变更加上从本地模型接受的变更。合并的模型成为存储库中模型的下一个版本,它也成为模型所有三个版本(起始,远程,本地)的后代。

并行开发模式

企业模型管理合适功能的存储库,拥有自动的并发检测和相关的工具,该工具能够自动启动合并操作。这就使得并行开发模式成为贯穿剩余规程的主流模式。

模式中的两个关键操作是 传播获取

  • 变更从层级结构中向下传播:从获得的外部模型向企业传播,从企业向项目传播,从项目向执行者传播。
  • 变更从层级结构中向上传播:从执行者向项目传播,从项目向企业传播。

图 4 展示了任意变更循环期间,拥有两个执行者的单个项目是什么样的(计时由本地政策创建)。

图 4. 并行开发模式
图形
图形

“推进”与“拉动”获取和传播

只与视角和政策有关。

正如前面在词汇表中定义的那样,获取是一种将变更 由下至上移动的操作;这就是说,在模型低级层级结构中所做的变更,现在移动到高层次的流中。传播是一种将变更 由下至上移动的操作;这就是说,在高层次中所做的变更移动到低层次后代的流中。

在执行者对并行开发模式典型的执行过程中,执行者开发流的所有者,执行所有这些操作。在一个项目中,允许执行者将变更推进到项目模型集成流中,并从流中拉动其他人的变更到执行者的开发流,以提供高级别的独立性和对执行者的控制性,这就确保维持了高生产效率。

但是,本地政策也许会抵触这种执行模式。例如,有一种政策规定只有项目模型管理员会执行获取和传播操作。这样一种政策的成本非常高,但是它能够提供很高的控制度。

当定义的政策控制模式的应用时,也可以作出相同的选择。这种层次的规程也许会从高级别的控制中获利,因为最后的结果要被变更为企业模型。

在大多数情况下,很可能由执行者来控制项目-执行者之间的接口;但是,企业模型管理员会控制企业-项目之间的接口。这是由本地政策对进程集中化的容忍度来决定的。

这里的关键点在于政策必须得到指定和记录。

维护起始模型

关键点在于每一个企业和项目中的工件都必须有一个起始。同样,每一对的工件必须有共同的起始。在获取期间将两个系列的变更集成到单个变更集中时,执行三方合并这种操作必须随时都能执行。

回到图 3,范例模型,企业模型和项目模型按照以下方式相关,起始向下流至后代:

范例 > 企业 > 项目模型

范例 > 企业 > 项目模型

并发版本中的每一个随后的获取,必须使用公共起始和 最新提交的版本与 本地模型的版本,来进行一次三方比较/比较操作(见于图 5)。

图 5. 在企业模型和后代项目模型流之间进行的三方比较/合并操作
图形
图形

模型起始应该在整个存储库以及所有的更新场景中,得到维护。千万不能使起始得到破坏,因为这会导致模型管理规程崩溃。

更具体的来说,每一个模型工件都有存储库中这样的关系。当您在阅读这篇文章时,您可以通过单个模型文件来理解获取和传播,因为任何一个高质量的存储库,都必须处理获取和传播操作期间,对多个工件所需的协调工作。

工件的企业层次的版本将会拥有企业层(工件以前的企业版本)的起始,或者工件获得范例版本层之上的起始。最终它们都会回归至执行者层,这在图 3 中并没有显示出来。

管理

这里描述的每一个操作和规程,都必须得到管理以提供任意时刻任意地方企业模型状态的清晰画卷。对于这个目的,您可以将模型 管理想象成与模型 管理操作和规程应用有关的环境和政策。

政策

模型管理政策需要在模型层中应用,例如,在企业和项目模型流之间应用。

在检查具体的场景时,控制场景,或者更精确的来说,通过定义处理模型管理关键问题的本地政策来对企业 调谐,都是没有意义的。关键政策问题举例如下。

推进和拉动获取与传播

这种政策处理的问题是,谁拥有权限在不同的模型层之间,来回移动模型变更。

在企业模型发展的不同时期,对范例、企业或者项目模型所做的变更,都需要进行传播或者获取操作。当您意识到需要将一些有价值的东西移动到另一个流中时,就需要这种操作了。

一个经典的例子是,需要从一个项目的模型中获取一个有用的新特性。在“推进”模型中,项目模型管理员会将变更推进到企业层次。在“拉动”模型中,企业模型管理员即那个变更从项目流中,拉动到企业流中。

注意每一个存储库操作都是相类似的;操作是由私人角色来执行的。实际上,选择或者决定接受什么的角色,要比执行具体操作的角色重要的多。下面是这些政策的范例:

  • 哪一个角色会赞成对企业模型所做的变更?
    • 企业模型管理员,模型管理员委员会
  • 哪一个角色将会获取企业模型?
    • 企业模型管理员,企业模型管理员
  • 哪一个角色将会传播项目模型?
    • 企业模型管理员,项目模型管理员

相同的政策问题适用于项目-执行者流的接口。

项目模型与企业模型的不同之处

本政策处理了后代流中有什么是不同的,以及它与起始之间将会维持多长时间的差异性。

在定义上,项目模型与企业模型总是存在一定程度的差异性。新的重要的特性会由于项目工作的结果,定期的获取到企业模型中。实际上,这就是企业层次上模型发展的主要机理。

企业必须建立回答以下问题的政策:

  • 项目在获取或者传播之后是否能够保持差异性?
  • 在强迫达成一致之前,项目和企业能够保持多长时间的差异性?
    • 一周,一个月,还是没有限制?
  • 多久对项目的差异性评审一次?
    • 每周,每两周,每月,或者从来没有?(“从来没有”是一种很坏的状态,因为企业模型管理员应该清楚的把握项目的状态)

项目和执行者模型的生命周期

该政策处理的是什么时候应用模型管理操作和规程(计时),多久进行一次(频率)。

创建项目通常是为了满足一项商业目标。组成团队是为了研究选项,直到发现方案为止。管理和回答以下问题需要政策:

  • 什么时候获取变更,多久获取一次?
    • 例如,每周五的下午,对模型所有项目执行者的变更,都获取起来,比较然后确认,以创建项目模型的新版本。
    • 或者两周获取一次,或者每月获取一次,又或者 ad hoc?经验证据表明,每周或者每两周获取一次是对公司最佳的选择。
  • 什么时候将企业模型变更传播到所有的项目,多久进行一次?
    • 例如,每周一上班工作开始的时候,将项目模型的新版本传播给每一个项目执行者。
  • 项目是否可以在特定商业目标之外存在?是否向项目继续分配新的商业目标?当项目完成了它的原始设计,但是它的模型和生成的工件仍然存在于企业流程中时,项目是否已经结束了?这里的问题是管理的总开销。
    • 一个项目通常会分解为它所完成目标的各个部分。
  • 获取和传播在项目之间是否保持同步化?每一个项目是否都可以为同步化创建它们自己的安排?
    • 同步化意味着所有的项目必须按照相同的间隔进行传播;不同步化意味着项目可以选择它们自己的计时方式。

操作

例如,您必须清楚的知道,什么时候项目已经“检入”到它的模型中,以及什么时候它们能够获取到企业流中。可以使用工具、报告和查询来评价模型的状态,并追踪访问入侵情况。

注意:
状态意识变更管理程序的使用,为项目的创建和管理,以及企业和项目流之间特性的移动,极大的提高了进程的质量。

通过变更管理程序,例如 Rational ClearQuest,来创建和管理工作和变更,使用标准或者通用的方案来改善需求和记录问题。这些记录通过不同的状态转化来工作(例如:提交 >分配 > 解决> 关闭),直到问题得到解决或者目标得以实现。

像 ClearQuest and ClearCase 这样的程序的关键特性,是它具有很强的查询功能。例如,它能查询数据库以决定:

  • 一个特定版本中任意两个日期之间所有进入模型的变更
  • 谁创建了模型中的变更,什么时候模型管理员批准了这些变更
  • 是否有访问入侵发生(例如,一个未授权的人执行了一次获取操作)

需求

当商业目标或者需求得到识别时,可以创建一条需求记录以获取目标和需求(商业“驱动力”),以决定最佳的工作方式确保目标的完成。这些工作通常包含了项目的执行,以分析和编辑企业模型。在这里描述的模型管理规程就能够发挥效果 了。

需求可以作为改进的请求(RFEs),或者发布变更管理软件程序(例如 ClearQuest)的请求来追踪。需求可以用词语或图片或者两者结合来描述。像 IBM® Rational® RequisitePro® 这样的工具,可以获取额外的需求信息,并且可以与 ClearQuest 紧密的集成起来,以进行严密的需求管理。

改进

在进行初步的分析之后,提出了一系列的改进方案,并在变更管理系统中整合成一系列的 RFE,或者分配给业务分析人员或者建模人员的任务。通过定期的更新到改进请求记录,可以追踪变更请求的发展过程,直到执行者解决了改进的问题。对于模型管理员来说,这就是工作已经完成并且可以评审的信。

在评审完之后,可以接受一项改进并关闭 RFE,或者将其重新打开以重新开始。这种循环会一直持续下去,直到工作可以完全的接受或者拒绝。当 RFE 被关闭之后,模型管理员或者执行者可以获取评审结果,并将验证后的变更整合到项目流中。

问题

当在模型中发现问题之后,可以立即将其当作一次 缺陷,注册到问题追踪(变更管理)程序中。改进也是按照同样的方式追踪的。模型管理员可以快速修复并关闭它们;但是,当一些缺陷聚集到正在开发中的区域时,缺陷报告会分配给处理该区域的执行者,然后缺陷就会在正常的改进工作中得到解决。

访问

企业模型管理员会定期的进行查询操作,并追踪所有的模型更新,以决定是否有违规操作发生。另一项重点是政策加强和报告,例如每一个项目能与企业模型保持多久的差异性。

历史和追踪

版本控制和加强的追踪系统会保持完整的历史信息,这样查询就可以在未来的任意时刻运行,以决定错误是什么时候产生的,并根据制定的政策来审计模型和规程。

一个有用的规程是,向企业模型注册每一次变更。同样重要的是,向企业模型注册每一个拒绝的变更,这样就可以避免混淆和争议。

结论

规范的管理操作,使任意规模的企业都能够对软件模型执行可靠且有效的并行开发。阅读本系列文章的第 2 部分,以得到关于工具未知规程的详细信息,展开对本文中引言部分的阅读。

本系列文章的随后部分,将会描述企业类变更和配置管理工具(例如,IBM Rational ClearCase 和 ClearQuest)中,对这些规程和操作的支持,还描述了有关建模和模型管理工具(例如 Rational Software Architect 产品提供的工具)的内容。


相关主题


评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=417969
ArticleTitle=治理和管理企业模型,第 1 部分: 引言和概念
publish-date=08032009