Rational Edge: 利用基于 RUP 的方法开发数据仓库 —— 第 2 部分:构建数据仓库,每次进行一个迭代

本文来自于 Rational Edge:两部分系列中的第二篇文章介绍了基于 Rational 统一方法(RUP)开发数据仓库(Data Warehouse)的项目在精化、构建和产品化等阶段中所进行的活动。

Scott W. Ambler, 实践负责人,敏捷开发,Rational Methods Group, EMC

Scott W. Ambler 在 IBM Methods group 中担任敏捷开发的实践负责人。他开发过程材料,在会议上演讲,并且与全世界的 IBM 客户一同工作,帮助改进他们的软件过程。 Scott 是许多书籍的作者,这些书籍都罗列在他的 Web 站点 www.ambysoft.com上。Scott 还是公认的 Rational 思想领导人,他的主页可以在此处看到。



2007 年 2 月 12 日

插图传统的,基于串行的数据仓库(data warehouse,DW)项目开发方法,仿佛不适应实际情况。两部分系列中的第二篇文章介绍了在利用基于 Rational Unified Process 的方法开发 DW 项目的精化、构建,和产品化阶段中进行的活动。该方法减少了商业和技术风险,而交付满足最终用户变化需求的高质量解决方案。Rational Unified Process®,或称 RUP®,以及前沿的敏捷数据库开发技术,例如数据库重构和数据库回归测试,证明是进行 DW 开发的有效过程。

第1部分中,我描述了一些关于 DW 开发的传统方法的难题,以及 RUP 如何解决它们。然后,我介绍了发生于 RUP 初始阶段过程中的活动,以启动项目,并处理与工作相关的范围风险。在第2部分中,我将介绍 RUP 团队如何成功地构架、实现,并将 DW 部署到生产环境中。如我在第1部分中所做的,我将继续使用 Behemoth Retail Company,一个虚构的组织,通过逼真的场景,我们为其开发数据仓库。

在整个文章中,我介绍了如何应用敏捷开发技术和基本原理。许多开发团队选择用敏捷的方式举例说明 RUP,而许多其他的团队选择到处借鉴一些敏捷的思想。我一直坚信尽可能地敏捷。

RUP 快速回顾

图 1 描绘了 RUP 生命周期,其依照了一种演进的(迭代且增量的)开发方法。由各种规程描述的迭代特性罗列在图的左手边:您在各种与需求、分析和设计、测试、程序设计等等相关的活动之间来回迭代。您随着时间开发增量的版本,每通过一次生命周期,生成系统的一个版本。此外,您在每个构建迭代的末尾生成工作软件,该软件可能在内部发布,用于测试或演示。

RUP 生命周期

图 1:RUP 生命周期

解决技术风险 —— 精化阶段

精化(Elaboration)阶段的主要目标是减少对项目的技术风险。通过确认反映您的团队所面临的高优先级技术风险的用例来做到这些,然后开发系统端到端的工作框架,以证明所提议的架构是有效的。对于 DW 项目,您的技术风险集中于数据量、对遗留数据源的访问和数据质量上。

让我们继续使用 Behemoth Retail Company 实例来进行研究。图 2 表示我们在初始阶段所确定出的用例的最初列表(该列表不完整,一般大型企业有上百个用例)。在项目过程中,该列表随后很可能变更,但目前,它是我们工作的起点。为了确定哪个用例表现出技术风险,我们需要了解单个用例的一般要点,这就是为什么我们最初在要点表中描述用例。我们还需要了解 DW 的架构策略,该策略要通过图 3 中 UML 部署图进行获取,该图也是我们在初始阶段所开发的。有时候,类似这样的图在精化阶段才进行开发,那是非常好 的 —— 您的团队需要让它们所处的环境有意义。

  • 分析市场活动的有效性
  • 分析区域内的库存周转率
  • 分析商店内的库存周转率
  • 一年后归档逻辑数据
  • 三个月后归档商店数据
  • 计算季节性的商店库存级别
  • 确定供应商交付效率
  • 确定一个商店每小时的员工需求
  • 确定区域的销售趋势
  • 确定季节的销售趋势
  • 为商店订购库存订单
  • 预测既定产品的供应商利润

图 2:Behemoth Retail Company DW 的初始用例列表

图 3:初始部署图

图 3:初始部署图

在分析了用例和当前架构远景之后,我们认定对 DW 的主要技术风险是存储数据量、存储数据的质量和供应商逻辑数据的复杂性。用例 分析商店内的库存周转率、 三个月后归档商店数据确定供应商交付效率好像覆盖到这些风险,因此我们将在精化阶段实现那些用例的适当部分。为什么是用例的一部分?因为我们当前的目标是解决风险,不是全部完成个别用例。我们可能决定将大型用例重新组织为若干较小的用例,并且因此能够实现完整,虽然是较小的用例,或者我们可能简单地决定在构建迭代中完成用例的实现。我更喜欢处理较小的用例并在单个的迭代中完成它们,但每种方法都可行。重新组织用例的一种策略是通过逻辑路径:如果有四个可选择的方针,您可能想将较大的用例分解成五个较小的用例,一个用于基本路径,其他每个用于一个可选路径。在重新组织之后,我们决定,我们需要实现 分析商店内的库存周转率、 三个月后归档商店数据确定供应商库存交付准确性

公共术语

  • 数据库重构(名词)。对数据库方案的小变更,这样可以在不变更语义的情况下改进设计。
  • 数据库重构(动词)。随着时间的变化,演进或安全地修复数据库方案的过程。
  • 数据库回归测试。在变更发生时,验证数据库功能和内容的行为。数据库测试应该用黑盒方式,其接口和内部应该用白盒方式。
  • 调查测试。超越功能需求的测试行动,确保测试目标如预期一样。
  • 确认测试。测试系统需求的行为。
  • 演化开发。实际上是迭代和增量的软件开发方法。

要实现分析商店内的库存周转率用例,我们需要确定遗留源系统,在此情况下,是图 3 中的 Store Sales 数据库。随着我们做更深入的情况分析,我们发现,部署图不是完全的准确。是的,有 Store 数据库,但有不同的版本。在过去的几年里,Behemoth 兼并了许多竞争对手,每个对手都有自己经营商店的方式。尽管 Behemoth 已经将这些商店转换为其自己的系统,但这项工作还在继续进行,并且将继续到接下来的几年。因此我们需要能够表明我们可以从三个不同版本的 Store 数据库 —— BehemothStoreDB、AlsoRanStoreDB 和 GaveItAGoodTryStoreDB 中抽取出数据,每个都有自己的方案。

同样的,要实现确定供应商库存交付准确性用例,我们需要从 Store Orders 和 Logistics 数据库中抽取数据。幸运的是,在整个 Behemoth 中,这些数据库是一致的,由于 Behemoth 在市场中的规模,因而它能够“推动”供应商按照 Behemoth 的意愿行事。数据是复杂的,但我们对结构的了解很充分。

三个月后归档商店数据 用例有一点不同。首先,它要求我们标记数据,以便随后我们可以确定数据的日期。无疑我们需要向单个行添加时间戳。其次,它要求我们去掉比较旧的数据并在别处存储。我们应该将去掉较旧的数据作为导入数据过程的一部分。再次,它要求我们访问归档数据,运行对保留三个月的存储数据的报告。

在精化阶段,我们撰写了足够的代码来验证架构。在这种情况下,我们将撰写代码,从三种类型的商店数据库、订单数据库和逻辑数据库中抽取数据。我们不需要从那些数据库中抽取所有的数据,我们也不需要完全净化数据,我们只需要表明我们可以用演示的方式完成。

我们还需要撰写一些使用该数据的典型报告。这些报告可能不恰当,并且我们可能不足够了解如何实现复杂的业务逻辑,但不论怎样,应该输出基本数据。我们还需要归档较老的存储数据,一些我们还没有想透的数据(图 3 中没有显示归档数据库)。最后,我们需要至少撰写一个有利于 DW 中活跃数据和归档数据的报告。

目前,可能通过 Java 或 Visual Basic 撰写这些报告,即使稍后我们可能决定使用健全的报告工具。此时,我们的团队还没有决定使用哪个报告工具,图 3 也没有描述这一点。我们知道有很多工具,因此,不知道选择什么确切的工具不是项目的风险,这是我们可以安全推迟的决定。是的,最终您可能选择例如 Eclipse BIRT 或 DB2 Query Management Facility 的报告工具。这种方法反映了小的软件开发团体的想法,并且是 RUP 所固有的 —— 我们不需要立刻看透所有事情,相反,现在我们将着重于关键风险,并将决定推迟到需要做出的时候。

我们还需要表示我们了解基本功能设计问题,特别是数据库规模设计和性能考虑。许多数据仓库的规模每年都会翻倍,因此我们可能想表示我们的架构是可扩展的,即使我们将选择在实际中,在随需的基础上扩展实际系统。换句话说,您可以为您的系统开发健壮的架构,并证明在不太苛刻的情况下它是健壮的。

如您所料,我们的工作产品会在精化阶段进行演进。例如,我们应该更新图 3 的部署图,以表明有三个类型的商店数据库,以及附加的归档数据库和归档程序。在我们分析源数据库的时候,我们会发现我们的概念模型需要更新,以反映我们对领域的了解改进了。这些模型在整个项目中会演进,因此我们需要为此做好准备。

在此,我们甚至想要开始一些种类的源到目标的映射。在精化阶段,我会建议将概念模型中的业务实体映射到遗留系统中的源数据库。在我们实现数据抽取代码的时候,我也总想向概念模型中添加属性,然后将它们映射到遗留数据源中的列上,但我只会以即用即做的原则(just-in-time,JIT),并且只有当其向整个项目提供价值时做这事。对于 DW 项目团队,陷入这种工作中是非常普遍的,因此我更倾向小心谨慎地犯错,并最小化文档的撰写,直到需求清晰时候再进行。

我们将继续演进需求模型,随着涉众对他们想要的了解的更多,我们来确定新的用例。更重要的是,在人们执行用例所描述的业务活动时,我们要着重于他们可能做出的报告和查询的类型。图 4 概述了简单报告规范的实例。注意该规范是多么洁简,概括关键问题,但不进入细节 —— 您可以在构建阶段以 JIT 的方式获得细节。许多 DW 团队在试图过分细化他们想实现的东西时会遇到困难,当我们知道涉众要改变想法时,最好制定一个并不精确的目标。较少地撰写文档和更高质量的工作软件应该成为工作的方式。

报告名称:商店的库存周转率
选择标准:
  • 部门
  • 库存种类
  • 产品
  • 日期范围
商业目标:
  • 确定库存需求
  • 个别产品的收益率
  • 部门的收益率
数据元素:
  • 部门
  • 产品描述
  • 产品编号
  • 利润
  • 库存数
  • 销售数
  • 价格
  • 每平房英尺的收益率
  • 库存种类
  • 周转率

图 4:最初的报告说明

我们在项目早期可以做的一件重要的事情是采用开发团队愿意遵从的实际的数据命名约定。处理空值的约定也很重要,当我们收到坏数据时就这样做。我们要接受或尝试修复它吗?我们要将问题报告给源系统的所有者,希望他们能最终处理这些问题,还是做最简单的可能事情,并且不进行报告吗?我通常倾向于尽可能处理数据,并向所有者报告所有问题。

在精化阶段,开发团队会犯许多共同的错误:

  1. 过度详细的需求文档。是的,我们需要了解需求,但那不意味着我们需要撰写许多文档。我能够为图 4 的报告说明撰写许多页的描述,包括实体模型。该工作怎样实现?总之细节可能变更,否定最初说明的价值,还要求我们将其更新,以反映涉众的新意图。事实是,图 4 为团队提供足够的信息,以了解基本信息,并且提供一个基础,在构建过程中,当我们实际上需要实现报告时,我们可以通过这个基础以 JIT 的方式分析详细情况。全面的文档不仅浪费金钱,并且通过向您提供安全错觉,将您的项目置于风险之中。
  2. 过度详细的设计文档。精化不是设计阶段,这是个“减少技术风险”的阶段。是的,您需要设计解决方案,但这不意味着您需要在您对系统了解很少时,预先进行设计。在 RUP 项目中,我们在生命周期的早期做一点架构建模,我们证明架构有效,然后我们在构建迭代中以 JIT 的方式处理细节。
  3. 撰写描述遗留数据源的详细文档。您可能会发现您甚至不需要访问这些遗留源,且您当然不用访问它们中的所有数据,因此,为什么在您实际需要时才将所有工作投入到文档撰写中?在此您想要及时了解数据源的约束条件,特别是总的数据质量,以及可用性/数据的时间选择,并且了解数据量。再次强调,细节可以在构建过程中进行处理。
  4. 过度详细的数据源到目标的映射。此时,您可能想要将概念模型中描述的业务实体映射到可能的数据源,但比这更详细的内容将减慢您的速度,并真正将项目置于风险中。如果您今天能够获取该信息,那么在您真正需要信息时,当然您仍旧有能力获取。
  5. 没有操作和支持人员的参与。在任何项目中,操作和支持人员都是关键的涉众 —— 操作人员对现有遗留系统如何工作非常了解,支持人员了解最终用户当前关心什么。此外,操作人员拥有重要的服务质量(quality of service,QoS)需求及数据仓库需要考虑的部署考虑。

要退出精化阶段,团队必须经过生命周期架构(Lifecycle Architecture (LCA)) 里程碑评审。该评审可以选择正式或非正式地进行,当然我更喜欢让事情尽可能简单并轻型。在 LCA 评审中,我们必须评审 DW 的业务案例,以确定是否有意义,根据我们对架构和需求的进一步了解来构建系统。我们的原则是,浪费两年项目中的三个月,比浪费三年要好。更重要的是,我们必须能够证明针对 DW 的有效且端到端的框架,这表明我们了解并处理了主要的技术风险。该框架是我们在构建阶段建立系统内容时所依据的。LCA 评审的基本目标是制定“行与不行”的决策 —— DW 必须在继续进行之前作出财务和技术的决定。

满足涉众的变更需求 —— 构建阶段

在构建阶段,我们以进化的方式开发数据仓库,将“内容”放入精化阶段所开发的架构框架。系统在迭代中构建。我发现,两到四个星期长的迭代最有效,尽管如果您不熟悉 RUP,您可能在使用该方法时需要首先花更长时间。构建迭代是一个时间段,在其末尾,我们会得到实现迄今最高优先级需求的工作产品。通过以这种方式工作,我们能够获得从涉众那里得到的定期反馈,包括我们了解他们实际需求的机会。此外,通过定期提供更新的软件,我们向涉众提供具体的证据,证明我们实际上发展了项目。软件开发项目发展的唯一真正的度量是工作软件的交付。

在每个迭代过程中,我们处理那些仍旧需要实现的最高优先级需求,有效地减少需求堆栈。如果我们的迭代长达两周,那么我们从优先级堆栈顶部取出值两个星期的工作。通过这种方式,我们总是为涉众的 IT 投资实现最大利益,从而减少金融风险。

系统,包括数据仓库的方案,将在项目过程中演进。这暗示着,我们需要采用许多演进的开发技术:

  1. 配置管理。配置管理的目标是在生命周期中管理项目的工件。这是如此重要的事情,以至于 RUP 包括特别处理这件事的配置和变更管理规程。存在许多配置管理工具,例如 IBM Rational ClearCase,这是您可以得到的。
  2. 持续的集成。持续集成的目标是无论什么时候有变更都重新构建系统,向您提供关于您所引入的变更是否破坏了什么内容的清晰反馈。工具,例如 IBM Build Forge,使您将项目中的构建和发布工作自动化。
  3. 重构。代码重构是对源代码的简单变更,是在不破坏任何东西,且不添加任何东西的情况下改进设计。类似的,数据库重构是对数据库方案的简单变更,是在不破坏且不添加东西的情况下改进设计。重构可以使我们的设计总是保持最高质量,因为处理清晰的设计比处理不可靠的设计更容易,所以它帮助使开发人员尽可能提高效率。更好的是,重构使我们随时间安全地确定现有的遗留资产。一个好消息是,代码重构工具被嵌入到现代集成开发环境(integrated development environment,IDE)中了,例如 Eclipse。坏消息是,由于数据库的重构还是一个非常新的技术,以至于只有一些初级的工具可用。幸运的是,如 Pramod Sadalage 和我在重构数据库中所描述的,1手动实现数据库重构是非常直接的。
  4. 回归测试。回归测试的目标是确保对系统的变更没有破坏现有的功能。因此,有效的回归测试是进化开发的重要推动者,因为我们一直都向代码基础中添加新功能。现代 IDE 拥有内嵌的代码测试工具,例如 xUnit 套件以及产品,例如 IBM Rational Functional Tester,可以用于数据库测试。

让我们假设我们处于 Behemoth DW 的第 5 个构建迭代。在前四个迭代中的每一个过程中,我们实现支持用例所需的功能,现在我们将在本阶段中做同样的事情。对于每个用例来说,您的一般策略是一样的:

  1. 确定所需的数据元素。因为我们花时间详细描写高层次的报告说明,例如图 3 中的内容,在精化阶段中,这将是相当直接的。否则,我们将在此迭代中与涉众密切合作,详细描述这样的说明,或简要地拟定报告的形式。不论哪个方式,我们可能不会确定整个迭代所需的所有数据元素,但我们将获得大部分。即使我们可以开发完整的列表,我们的涉众在看了我们所构建的东西后也可能改变想法,因此我们需要准备好在迭代的后期处理附加的元素。
  2. 确定数据元素的来源。对于每个元素,我们需要为其确定最好的来源。有时候,在 DW 中已经具备了该元素,并且在表面上,可能表现出,我们已经为其做了所有事情,但我们仍旧想确保这是真的。在项目的较早期,我们可能为该数据元素获取了整个数据的子集,但这对新报告可能是不够的。例如,也许我们已经为所有的纺织品获得了库存信息,但现在我们需要获取关于食物的来自于新数据源的库存信息。一些数据元素对我们是全新的,我们还没对它们进行抽取。
  3. 演进 DW 数据设计以接受新数据元素。我们将需要添加新列,甚至是新表,来存储新的数据元素。为了维护数据库设计的质量,我们甚至可能发现,需要重构现有数据库方案中的某些方面。
  4. 开发抽取代码以获取丢失的数据元素。对于每个元素,我们需要开发代码来抽取,有必要时变换或净化,并将其加载到 DW 中。处理遗留数据问题,从判断数据质量的分析工作,到撰写用于净化的变换代码,常常证明要花费大部分开发时间。当数据元素出现在我们已经从中抽取数据的数据源中的时候,我们只需要将其添加到现有的抽取代码中。如果元素出现在我们还没有访问的数据源中,我们不得不首先访问该数据源。下面对此进行更多说明。
  5. 开发所需的报告。有时候我们只需要让数据用于查询,有时候我们要开发健全的报告。在后者的情况下,或者当我们扩展现有报告时,我们将需要做一些编码工作。
  6. 测试、测试、测试。如我上面所述,我们用进化的开发方式充分地进行回归测试。
  7. 从涉众那里获得反馈。一旦我们开发了新的报告,更新了现有的,或为特定的查询提供一些新的数据元素,我们就尽快将其展示给涉众,以获取反馈。我们将经常听到这样的评论,如“这相当好,但不全是我想要的,你可以...?”这正是我们想听到的,因为这可以使我们返工,以便 DW 满足他们的实际需求。
  8. 迭代。RUP 迭代不是迷你瀑布型,在其中您先进行所有需求分析,再进行所有设计,然后进行所有程序设计等等。一些人试图将其进行这样地组织,并且如果您以 RUP 的方式开始。“迷你瀑布”的概念是一个好的开始,但最后,您会发现,您将在我在上面所描述的步骤之间来回迭代。别着急,这是正常的。

根据组织中策略的级别不同,最初对数据源的访问可能从非常简单到实际上不可能。理论上,您应该做的所有事情是与适当的操作人员谈话,然后与他们合作获得您需要的文档和访问权。您可能还需要和他们一起做一些功能计划,因为 DW 的抽取需求可能过度地对遗留数据源施压,因此需要升级。不那么理想的是,您可能会遇到某个政客,通常在组织中职位很高,他会不顾一切地保护他们多年构建的帝国,并且打算用他或她的权力做任何事情来阻止您访问他们的数据。

您将希望确定有关现有数据源的一些关键信息:

  • 可用性是什么?24/7?在特定时期内?
  • 访问媒介是什么?网络访问?磁带?DVD?
  • 您怎样访问它?通过 SQL 调用?通过 web 服务?
  • 谁是数据源的联系人?
  • 需要什么样的安全访问权?
  • 导入数据的结构是什么?

从建模的角度看,我总是发现描述 DW 方案的和描述遗留数据源的物理数据模型(physical data model,PDM)目前为止是项目中最关键的模型。如果您不了解您目前处理的数据的物理结构,那么您就有大麻烦了。这不意味着您需要预先了解所有东西,这只意味着您需要了解目前您正处理的内容。工具,例如 IBM Rational Data Architect(RDA)和 Computer Associates ER/Win 是物理数据建模的好选择。

第二重要的模型是用例,因为它们描述人们在实际中如何用 DW,通过对它们的洞察,可以确保 DW 满足其最终用户需求。用例用工具,例如 Microsoft Word 或 Wiki 写成,用例图通过 IBM Rational Software Architect(RSA)或 Microsoft Visio 绘制。

第三是数据源到目标的映射,因为人们,包括最终用户和开发人员,想知道数据从那里来。如果您的映射是简单的,那么例如 Microsoft Excel,甚至 Wiki 的工具可能就足够了。对于较复杂的,尝试使用元数据管理工具,例如 Rochade 或 Datamapper。

第四位的是详细的逻辑数据模型(logical data model,LDM)。LDM 的潜在价值是它们提供 DW 支持的、对业务实体的技术独立概述。然而,实际上,似乎逻辑数据建模与几乎不向组织提供真正价值的官僚作业没有差别。如果您将创建 LDM,那么我强烈建议您只获取向您的团队提供立即收益的那些模型中的信息。IT 部门中太多的官僚主义似乎被起因于较高层次的文档编制的未来生产力改进的主张证明是正确的,但从长远看,那些利益似乎不能被实现。

下面是我们在 DW 项目的构建阶段中想要避免的一些共有的错误:

  1. 采用数据强化的方法。人们想要满足其业务需求的报告,因此着重于实现这些的功能。这意味着我们需要以用途为中心的开发方法,不是以数据为中心的方法。数据无疑是全景中重要的部分,但它只是许多部分中的一个。如果我们着重于数据,而不是用途,我们会冒构建了一个没有人喜欢使用的数据仓库的风险,这是传统数据仓库工作中太普遍的事件了。
  2. 依据数据源组织工作。在 RUP 中,我们在构建阶段根据需求组织工作,不是根据技术问题。换句话说,在已知迭代中,从数据源 X 中获取数据所需的工作不用都做。相反,我们做这样的工作来满足具体涉众的需求。在每个迭代中,我们从系统 X 中再获得一些,从系统 Z 中获得一些,等等。
  3. 撰写详细的报告说明。遵从短迭代,也许是几周的时间,并在每次迭代的末尾提供工作软件,常常产生了对获得更多软件比获得更多说明更感兴趣的涉众。有效的 RUP 团队关注高价值的活动,例如实际地开发报告,而不是只撰写您在未来某时打算交付的内容。
  4. 不适合的工具。构建数据仓库是负责的工作,如果您希望成功,您需要好的工具集。
  5. 与涉众缺乏协作。在 Communication Breakdown2 中,Rick Sherman 指出对于商业智能(business intelligence,BI)项目(DW 项目是其的子集)的最大风险之一是缺乏沟通。他所描述的所有沟通难题都源于过分强调数据问题的传统串行的开发方法。相反,RUP 是进化过程,它促进涉及涉众主动参与的用例驱动的方法。
  6. 与数据源所有者缺乏协作。要成功地构建数据仓库,我们必须与遗留数据源的所有者密切协作。他们远远比我们了解数据,因此与他们进行一点点有效的协作就可以显著地减少整个开发成本。是的,您可能不得不撰写净化导入数据的代码,但这是工作的本质。

要退出构建阶段,我们必须通过初始操作能力( Initial Operational Capability(IOC))评审。该里程碑的目标是确保 DW 已准备好进入产品化阶段,涉众仍旧支持 DW 的部署,并且业务用例仍旧有意义。

将数据仓库部署到生产环境 —— 产品化阶段

产品化阶段的目标是成功地将数据仓库部署到生产环境中。您需要与最终用户沟通部署计划,如果您要增量地部署或立刻部署到最终用户那里,就得这样做。此项沟通工作将采取电子邮件、总体介绍和最终用户培训的形式。在形成数据仓库的第一个版本过程中,最终用户培训可能是重要的工作,因为大多数,即使不是所有最终用户,对报告和分析工具是不熟悉的。对于仓库后继的版本来说,培训工作应该减到最小,因为您只需要告诉他们可用的新数据。

在产品化阶段,您将执行最终验收和系统测试,但如果您在精化和构建阶段中彻底地进行了测试,那么该工作只是走形式。事实上,此阶段中所犯的最共有的错误是认为这只是测试阶段。生命周期末尾的测试是最糟糕的可测试时间,因为确定缺陷的成本随您找到它的时间成指数级上升。

只是开始 —— 随时间生成增量版本

成功的数据仓库是一个生命周期可以延续几十年的产品。问题在于不是将其作为单个项目进行开发,而是作为一系列的项目。这个含义是,一旦您发布了产品,您的团队将发现自己再次回到构建阶段的开始,实现新的需求。马不停蹄。

如我在此两部分的文章中所描述的,依据 RUP,对 DW 开发采用进化的方法不仅是可能的,坦白地说,这对您是最值得的选择。通过在项目早期处理范围和技术风险,然后增量地开发 DW,以便您可以在生命周期中展示具体的进展并获得反馈,您会显著地提高生产力以及开发出有用的 DW 的可能性。

我想听到您对本文及我在文中所表达的思想的反馈。我定期出现在developerWorks 的 RUP 论坛上,那么请将您的评论发到那里。我们期望能进行有趣的谈话。

致谢

我想要感谢 Per Kroll、Christine Posluszny 和 Mike Perrow 的反馈,通过这些反馈我改进了本系列的文章。

注释

1 浏览 Scott W. Ambler 和 Pramod J. Sadalage 撰写的 Refactoring Databases: Evolutionary Database Design,Addison Wesley Professional:2006。 http://www.ambysoft.com/books/refactoringDatabases.html

2 参见 Rick Sherman,“Communication Breakdown: The Achilles' Heel of BI Projects”,DM Review Magazine,2006 年 11 月。

参考资料

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=195236
ArticleTitle=Rational Edge: 利用基于 RUP 的方法开发数据仓库 —— 第 2 部分:构建数据仓库,每次进行一个迭代
publish-date=02122007