内容


将数据从 Rational DOORS 迁移到 Rational DOORS Next Generation

计划并实施一个 DOORS 迁移项目

Comments

或许成功的产品和系统开发的最基础任务就是收集需求,然后创建一个阐述最终产品的共同愿景的产品规范。收集的需求明确了从功能到性能的所有条件。它们记录了已知限制来帮助避免过失,未检测到这些过失的时间越长,代价就会越高。任何现代项目的开发周期都离不开每次迭代之间和每个阶段之间的中间结果。 没有什么能够替代有说服力的需求,它们为正在进行的项目指明重点并明确说明项目。

传统静态文档中捕获的需求具有一些缺点:

  • 文档很快过时。
  • 文档缺少一种检测和处理过时的机制,这使得项目从第一天开始就面临越来越大的风险。
  • 文档无法扩展,所以许多利益相关者之间的合作不够灵活且容易出错。

像 IBM Rational DOORS 这样的需求收集应用程序显著增强了各个规范的协作和报告,而且可以扩展到大型团队。但是,胖客户端的安装和维护方面存在负担。还缺乏用于实现公共管理、可跟踪性和报告的更大的生态系统。 这限制了这些第一代客户端-服务器需求管理应用程序的最终潜力。

IBM Rational Collaborative Lifecycle Management Solution (CLM) 是一个第二代套件,它将需求管理应用程序 IBM Rational DOORS Next Generation、软件配置和流程管理应用程序 IBM Rational Team Concert™,以及质量管理应用程序 IBM Rational Quality Manager 组合到一个紧密集成的生态系统中,在该系统中,可跟踪性链接是第二天性。

借助仪表板和 IBM Rational Publishing Engine,可以实时从整个系统拉取信息来创建报告,显示项目的状态以及变更或问题对系统中任何地方的影响。CLM 还通过基于浏览器的用户界面解决了总体拥有成本,同时提供了协作特性,比如审核、可视编辑、文档生成、报告、审计历史和一个通用的管理接口。

因此,第一代需求管理应用程序的长期用户可以转而使用第二代工具套件(比如 CLM),解决全球化以及扩展或地理分布的其他压力所带来的团队开发问题。

从第一代需求应用程序、信息架构和方法向 CLM 套件迁移是一个非常宽泛的主题,超出了本文的讨论范围。本文其他部分将重点介绍需求和相关信息架构的迁移。CLM 问题会在合适的地方提及。

术语和定义

本文假设已经有一个项目,用于创建组件、产品、系统或特性的版本。这个列表不完整,但目标明确。为了避免在引用时笨拙地使用任何或所有这些术语,本文其他部分将使用术语产品表示所有这些选项的新版本。

需求的核心是定义该产品的新版本必需的特性或行为的一条语句,因此使用了术语必须来定义需求。例如“月球单元必须包含一个呼吸器,生命才能维持。”一个被强烈渴望的特性通常使用应该指定,一个可有可无的特性使用可以指定。

一组这样的需求和所有说明信息都被捕获到一个规范中。例如,在 DOORS 和 DOORS Next Generation 中,规范都使用一个模块工件表示,该工件本身将一组工件归为一组。

使用 DOORS 和 DOORS Next Generation 时最常用的术语是:

项目
在 DOORS 中,项目是一个特殊化的文件夹,它可以包含子项目、文件夹、模块和工件。在 DOORS Next Generation 中,项目区域是团队的自成一体的一个区域,或者是特定项目(出于安全目的)。项目区域的成员可以查看该项目区域内的任何工件。非成员无法查看任何工件。
文件夹
文件夹可以包含项目(仅限 DOORS)、子文件夹、模块和工件。请注意,从 DOORS 迁移的项目在 DOORS Next Generation 中变成了一个文件夹。
模块
一个由大量工件组成的规范。模块本身也是一个工件。模块具有顺序和分层结构。
集合
一组工件(仅限 DOORS Next Generation)。这不是一种包含关系,它也不是一个模块。集合没有顺序和分层结构。
工件
单个需求或其他信息,比如文本、图片、表格或其他某个对象。在模块的上下文中,它对过滤器可以是可见或不可见的。在 DOORS 中,工件仅存在于文件夹中,或者可以存在于模块中。在 DOORS Next Generation 中,工件存在于文件夹中,而且可在任意数量的模块和集合中重用。因此,DOORS Next Generation 支持采用共享工件的概念。请注意,工件可以包含嵌入式工件,从而提供了分层结构的另一种形式。
属性
工件中的字段,类似于数据记录中的字段或分类器中的属性。在网格视图中显示为一个列。对视图可以是可见或不可见的。
类型
应用于任何工件或属性的数据类型。在 DOORS 中,类型位于各个模块的本地位置,会在要跨多个模块使用相同的类型和形状(属性的编号和名称)时复制。在 DOORS Next Generation 中,类型是在项目区域中全局定义的,在需要重用或标准化时,会在项目区域之间复制整个类型系统。DOORS 和 DOORS Next Generation 支持使用模板来填充其类型系统。 例如,DOORS Next Generation 拥有系统和敏捷需求等方面的模板。
链接
内部 DOORS 链接的简写形式,这是从一个工件到同一个模块中的另一个工件、从一个工件到另一个模块中的另一个工件,或者未加入模块中的核心工件之间的指针。DOORS 和 DOORS Next Generation 中都有链接,但核心工件链接仅在 DOORS Next Generation 中受到支持。
OSLC 链接
一个指向启用了 OSLC 的外部应用程序(比如 Rational Quality Manager、Rational Team Concert、DOORS、DOORS Next Generation 等)中的资源的指针。
外部链接
有时称为普通外部链接 (vanilla external link),这是一个指向另一个平台或应用程序上的资源的 URI 或等效指针。

信息架构和工作方法迁移

多年的需求方法和数据的演变,代表着信息架构、系统和工具架构以及工作方法中的重大投资。因此迁移不仅仅是将数据从一个数据库移动到另一个数据库。在组织转型中,对成本和风险的重视实际上超过了对移动数据的行为的重视。

针对第二代协作式工具套件的组织转型包括:工作流和方法;工具技能和教育;以及信息架构元素,比如模块结构、需求形式和属性、数据类型系统、项目组织、文件夹分层结构、数据和报告工具(格式和模板),等等。

任何时候的更改都会带来风险,比如混乱和失去惯性 (loss of inertia)。 但是,利用最新的需求工具迁移到第二代协作式生命周期管理环境,是修复信息架构、工作方法、工作流和协作中的已知问题的绝佳时机。

所以关键分析结果会提供一种能够推动 DOORS Next Generation 中的活动工作 (active work) 的信息设计和架构。DOORS Next Generation 中的新项目依赖于这种规划水平,从 DOORS 迁移的活动项目会进一步从数据库中的数据模型一致性和继续遵守更新的信息架构中受益。

需求数据和方法生命周期

需求数据生命周期在三个可识别的阶段与需求迁移进行交互:

  • DOORS:在这个阶段中,将会创建并积极地使用原始 DOORS 数据。这通常适用于任何第一代需求工具。
  • TRANSITION:一个可能非常长的阶段,在这个阶段中,会以递增方式迁移需求数据,直到 DOORS 中不再有活动数据。此阶段可能持续数年,在活动项目具有较长生存期的环境中,此阶段甚至可能持续几十年。
  • DOORS Next Generation:在这个阶段中,DOORS 数据库是一个历史归档文件,所有当前和未来的工作都会在 DOORS Next Generation/CLM 中进行。

请注意,可以对 TRANSITION 阶段进行组织,这样活动团队和项目就不会有重大中断或破坏。强烈建议避免匆忙进入 DOORS Next Generation 阶段,避免此过程中损坏活动项目的风险。从 DOORS 向 DOORS NG 的迁移(可能是向 CLM 迁移的更大迁移项目的一部分)的完整时间线可能类似于图 1。

图 1. 从 DOORS 向 DOORS Next Generation 的迁移的 TRANSITION 时间线
Adoption of DOORS followed by TRANSITION to DNG.
Adoption of DOORS followed by TRANSITION to DNG.

成熟的 DOORS 数据库经历了逐步发展的过程,从成立之初到需求数据可能处于某个迁移点的当前状态。通常,在几年或者甚至几十年后,一些数据可能已过时,或者形成了一种混乱的或纠缠不清的状态(有时称为意大利面条式需求),这不是当前项目或新项目想要的状态。因此,最佳实践是通过仅迁移与持续开发和未来开发相关的工作主体,最大化效率和明确性。

最好以递增方式移动 DOORS 数据,比如逐个项目地移动,或者甚至以部分项目作为一次增量。如果从一开始就采用增量迁移序列,那么整个流程会更加顺畅。该流程是非破坏性的,而且 DOORS 可以成功迁移:

  • 项目
  • 模块,
  • 工件
  • 链接
  • 文件夹分层结构
  • 图片
  • OLE 项目
  • 表格

迁移包中的数据(比如完整或部分 DOORS 项目)在迁移的前一天还保留在 DOORS 中,但在迁移之后,它会保留在 DOORS Next Generation 中。迁移的数据在 DOORS 中被设置为只读,并通过来自 DOORS Next Generation 的反向链接进行引用。这使得 DOORS 中的原始项目对该项目在 DOORS Next Generation 中的新版本可见。 您可以跟随反向链接导航到历史数据和基准数据。根据本地客户端配置,反向链接会打开胖客户端或 DOORS Web 客户端。

需求数据迁移项目

一个需求迁移项目有 4 个阶段:

  • 分析:信息架构、工具和方法迁移规划。包括对新信息架构的部署、培训、教育和设计的工作量和成本的估算。还包括现有 DOORS 数据的形式、规模和健康性的风险和成本评估,要留下的过时数据和要迁移的活动数据的识别。最终结果是一个通过开展培训和教育工作增量迁移到新信息架构中的计划。数据迁移的细节包括一系列的迁移包和首选顺序。分析阶段仅在整个迁移项目开始时执行一次。
  • 准备:清理和规范化数据,删除或修改属性定义,以及协调数据类型。最终结果是数据,该数据已经过规范化,且与 DOORS Next Generation 中的目标项目区域兼容。准备阶段仅对每个增量迁移包执行一次。
  • 执行:导出 DOORS 数据并将其导入 DOORS Next Generation 中。最终结果是 DOORS 中的锁定数据以及 DOORS Next Generation 中的活动数据,具有 DOORS 历史版本的反向链接。执行阶段仅对每个增量迁移包执行一次。
  • 后期处理:对 DOORS Next Generation 中的类型的可选连续工作,包括协调属性和工件类型。用户、权限、团队区域等的管理。后期处理(如果需要)阶段仅对每次增量迁移执行一次,但可以随着新信息架构中的数据和方法的成熟继续存留。
图 2. 典型的增量 TRANSITION 项目的时间线
Migrations phases are performed incrementally.
Migrations phases are performed incrementally.

简介中已经提到过,最好将迁移作为一个增量流程来执行。每个增量包含三个阶段: 准备、执行和后期处理。此外,和任何增量流程一样,这些增量(迭代、冲刺)从某种程度上讲是自成一体和重叠的。这意味着每个迁移增量都可以和其他增量一起并行运行,这完全取决于可用的资源。也可以按顺序运行它们,使风险最小化,或者适应共享类型中的大量重叠。同时执行 DOORS 中的准备阶段和 DOORS Next Generation 中的后期处理阶段,是根据需要缩短增量之间时间的一种无风险方式。

图表显示,随着时间的推移,DOORS 数据库中的归档项目的比例会不断增加,直到全是归档项目,TRANSITION 阶段包含许多必要的重叠增量迁移,以便将选定的需求项目迁移到 DOORS Next Generation 中。

通常,DOORS 与 TRANSITION 的分界就是开始执行分析的时刻。TRANSITION 与 DOORS NG 的分界就是不再有规划好的迁移增量的时刻。

分析

分析阶段仅在组成大量 TRANSITION 阶段的实际增量迁移之前执行一次。现有设计和数据的全面分析,以及设计迁移和增量项目或部分项目迁移的详细计划,都会对 DOORS Next Generation 将来的成功产生很大的影响。

确定迁移的总规模(要迁移哪些项目以及何时迁移每个项目)并估算总工作量。为了帮助实现规划,DOORS 集成了实用程序来评估项目,以确定对象、链接、OLE 对象、属性等的数量和大小。风险评估在执行初始计划和数据评估时执行,以揭示资源可用性等因素对项目时间线的潜在影响。评估和计划将需求交换从 DOORS 转移到 DOORS Next Generation 的可行性,这将在后面几节中介绍。

最后,为每个增量迁移包选择一个目标 DOORS Next Generation 项目区域。对于新项目区域,定义一个文件夹分层结构和模块结构。对于现有项目区域,选择或创建已迁移数据的目标文件夹位置。如果需要,可以规划团队区域,从 DOORS Next Generation V6 开始,可以为每个项目或团队区域规划一种流结构。

准备

迁移实用程序记录 了DOORS 数据和类型系统的条件。DOORS 类型是有模块范围的,所以随着时间的推移,会产生细微的变化。这些变化应该识别出来,如果变化不是有意造成的(比如产品或地区变化),必须在执行迁移之前解决它们。这个协调和整合过程避免了数据类型污染,同时利用了 DOORS Next Generation 中丰富的类型系统支持。DOORS 迁移支持可以根据属性名称自动生成一个类型系统,这可以节省大量的类型系统映射工作。但数据必须是干净和规范化的,这样该特性才能生效。

对于现有的 DOORS Next Generation 类型系统,可在必要时执行协调,数据类型使用其 URI 与目标类型系统保持一致。正如前面提到的,自动化的 DOORS 迁移工具会在增量之间生成一个一致的类型系统,所以只在打算迁移到一个最初未填入 DOORS 迁移输出的项目区域中时,才需要手动调整类型系统。

DOORS 迁移指标实用程序用于执行类型的协调和整合。检查属性和枚举的报告,必须特意地或根据协调的需要来识别和分类类似的或仅名称不同的类型。这可以获得一个通用的类型集,消除 DOORS Next Generation 类型系统中的重复和杂乱。准备好迁移类型系统后,利用 DOORS 中的迁移支持以直观方式继续执行增量迁移,该支持会负责实现 DOORS Next Generation 中的类型系统一致性、反向链接,并将数据转换为与 DOORS Next Generation 兼容的格式。

执行

DOORS 导出一个包含所有数据和元数据的迁移包,使 DOORS Next Generation 能够维护它离开 DOORS 时的数据的高度保真表示。这个包以导入任何 REQIF 包的相同方式导入到 DOORS Next Generation 中。

迁移的数据包含 DOORS 中的源数据的反向链接,提供了直接导航访问来审核基准数据和历史数据。DOORS 客户端和 DOORS Web 客户端都可以用来审核基于 DOORS 的数据。因此,该过程会逐步允许团队在 DOORS Next Generation 中工作,并继续拥有访问 DOORS 中未迁移项目和已迁移项目的历史数据的能力。

后期处理

后期处理是一个可选阶段,如果 DOORS Next Generation 中的类型系统需要做一些调整,或者如果没有在分析或准备阶段中完成初始团队和用户设置,就会出现这个阶段。在后期处理阶段完成后,团队就拥有了 DOORS Next Generation 中的所有需求数据,所有活动工作都会在这里执行。

需求数据交换

需求数据交换本身就是一个主题,但它常常与需求数据迁移混淆,所以值得简单讨论一下。

在原始设备制造商与提供商或合作伙伴之间交换需求,以指定采购某个组件或部件,这种现象很常见。要获得达成一致的最终规范,需要一个审核和修改周期。一组特定的需求可能被来回反复发送,并加载到协议的每一方使用的需求管理工具中。这个流程称为往返。当然,还有其他相关场景。例如,可能将规范发送给某个提供商,然后定期更新。这个场景称为带更新的交换,它的特征是需求反复朝一个方向传输,且不会在另一个方向上更新。

显然,协议的每一方都必须支持一种通用的需求交换格式和方言,此交换才能生效。这里使用了术语方言来表示每个工具应用于已交换的包内的特定数据项的语义。如果它们不匹配,那么达成一致的规范中可能会产生一些小错误。DOORS 已存在数十年,它支持多种交换格式,包括 REQIF、RIF、DOORS eXchange 格式、CSV(用逗号分隔的值),以及 DPA (DOORS Project Archive) 和 DMA (DOORS Module Archive)。另一方面,DOORS Next Generation 从 V5.0.2 起开始仅支持 REQIF,REQIF 是目前全球的需求交换标准。

需求数据交换在 DOORS 数据库之间使用往返格式,比如 REQIF、RIF 和 DOORS eXchange,并在 DOORS 与 DOORS Next Generation 数据库之间使用 REQIF。CSV 往返格式支持 DOORS Next Generation 6.0.1 中的传输,Microsoft Word 往返格式支持正在考虑中。

作为一个高级项目,从一个工具向另一个工具的迁移(比如从 DOORS 向 DOORS Next Generation 迁移)可能影响需求交换。DOORS Next Generation 目前必须使用 REQIF 交换数据,在 6.0.1 中必须使用 CSV。在现有关系采用不同的格式进行交换的地方,这可能是一个已知的进入障碍 (barrier to entry)。

但是,DOORS 因为历史原因而应该保留,所以提供了使用 REQIF 以外的一种格式在 DOORS 中继续执行这些交换的选项。这种情况一直持续到交换的双方协商出另一种往返传输格式。可以使用 REQIF 定期将规范从 DOORS 更新到 DOORS Next Generation,并链接到 CLM 的剩余部分。这个额外的步骤的确使迁移和交换更复杂,所以仅在最终协商出交换规范之前必须将交换规范链接到 CLM 的剩余部分时,才会利用这一步。如果审核的规范在最终确定之前一直是独立的,则不需要定期更新 DOORS Next Generation,而且在可预见的未来,可以继续像平常一样在 DOORS 中执行交换。

最重要的一点是,需求迁移不是需求交换,反之亦然。它们有不同的目标和成功条件,而且尽管每次迁移迭代都有相对较短的生存期,但交换可以无限期地进行下去。

结束语

IBM 提供了一个迁移框架,该框架支持一个随时间的推移不断分散成本和风险的增量过程。数据迁移及架构和系统转换都能从规划和执行阶段的分阶段中获益。与传统的“一次性大规模”产品迁移相比,增量数据迁移可以进一步减轻对活动项目的影响。

迁移的目标是利用 DOORS Next Generation 中的特性,同时放置新的和迁移的数据来利用 CLM 中的特性。 与提供商和合作伙伴的现有关系可通过将 DOORS 持久化为一个历史记录来获得支持,从而减轻这种迁移的破坏潜力。

与任何领域中的任何项目一样,规划和执行都是成功采用这些新一代需求工具的关键。


相关主题


评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=1024542
ArticleTitle=将数据从 Rational DOORS 迁移到 Rational DOORS Next Generation
publish-date=12212015