实例解说Rational Asset Manager

　　文章的下半部分介绍了资产管理在软件开发周期中如何发挥作用。Rational Asset Manager 与 WebSphere Service Registry and Repository、Rational ClearCase 和 Rational ClearQuest 相结合，管理和促进各部门之间的协作。这个业务场景解释说明贯穿了整个软件开发过程。

　　场景：一个保险公司的软件资产

　　JKE Enterprises 是一家虚构的保险公司。他们实施 Rational Asset Manager 来解决如何有效重用资产这个日益严峻的问题。他们对资产管理很感兴趣，因为他们的公司的数据库和文件系统遍布全球，而且已经相当庞大、复杂，其它部门和地点的人员很难检索、查询和使用既有的资产。

　　他们现在使用 Rational Asset Manager 管理公司所有既有的过程、设计、体系结构模型、开发过程和测试用例。这样，每个员工都可以检索公司的资产。在这个场景中，他们即将增加新的索赔处理能力，这是一项针对个人和家庭保险的高级 Web 服务。

　　JKE Enterprises 最近突然发现，经常复用的一个开源组件的 GPL 许可证发生了变化。用了几周的时间，才对使用开源汇报技术的团队和资产进行了量化。管理人员也担心访问不到需要的信息。他们不能够很快将问题通知给合适的团队，也不能提供出一个清晰的替代资产清晰的方法。

　　公司已经有了一个服务登记。但是，现在面临着激增的不一致的服务的挑战。他们需要管理服务资产开发，以确保机构中服务的一致开发，这样，就能够及时发布登记，并在应用服务器上合理布署。IT Operations 团队发现有的开发人员使用 Web Services Description Language (WSDL) 和 XML 文件创建服务。一些更为出色的开发人员正在努力，将服务的描述、支持人员等信息与测试数据和脚本一起包括在内，那么，在发布和布署的时候，就可以方便地对服务检验和测试。

　　计划和实施场景

　　JKE Enterprises 需要一种持久的方法，以便于开发人员检索所有资产，包括能够复用的服务。公司也需要控制不同的团队都能够重用的服务，并将服务资产的可追踪性进行文档化。以下是为实现目标而采取的几个步骤：

　　活动1：确定问题的本质和范围

　　JKE Enterprises 已经创建 Web 站点，并想要扩展该站点的能力。Eric 是执行团队的一名成员，主张新的索赔处理功能，认为这是一个好机会，可以降低顾客支持成本，消除索赔处理中的手工工作量。他将自己的想法上报董事会。经过商讨，董事会决定安排人员开展这项工作，积极探讨可行的技术方案。

　　活动2：确定资产

　　CIO 确定架构团队，并规定了哪些类型的资产需要进行管理。他们在 Rational Asset Manager 中按照需要的属性创建了服务资产类型，比如名字空间、local名称、支持人员。包括与 服务方针资产、服务接口资产和服务实施资产之间的关联。他们确定了方针资产必须包括 .policy 文件，服务资产必须包括WSDL和XML工件，但是对于服务实施资产没有作约束。另外，他们使用基于资产的开发文档来指导定义资产的过程。

　　活动3：在资产的储备、复查和控制方面达成一致

　　管理团队讨论了哪些部门将承担项目中维护资产的任务，进而提出一个综合的财务计划。管理团队回答了以下问题：哪些团队将维护资产?多长时间作一次更新比较合适?怎样对更新作出传达?

　　JKE Enterprise 面向顾客、基于 Web 的解决开发团队将拥有这些的资产。开发部门将发布与当前过程模型相符的、正式更新的在线代码。这次更新包括了文档和代码，但是将限制非决定性用户的接口更改，保持了下次主要发布中关键的GUI修改。当前所有得到合法批准的用户都将接收到包含开发工作和代码更新时间的 e-mail 通知。

　　活动4：确定过程模型

　　小结：在这部分场景中，Annie 找到了公司既有的过程模型并对之进行评估。论坛包括帮助她快速找到模型的相关信息。

　　Eric 给 Annie 发送 e-mail，分析负责所有面向顾客的基于 Web 的解决团队，并讨论计划方案。Annie 和 Eric 一起列出需求。然后，Annie 使用 Rational Asset Manager 检索其它部门中既有的任何过程的模型，用既有模型与之前列出的需求相比较。Annie 输入关键字 Claims、Process、Model ，找到了13个不同的过程模型。接下来，她浏览每个模型的描述文本和工件，确定了其中两个有直接关联的模型，又从论坛中查找与资产相关的资料。

　　每一个用户都可以对 Rational Asset Manager 论坛作出自己的贡献，而且这些论坛还与Rational ClearQuest相连接。Annie 阅读了论坛的大量资料，发现其中一种方案存在缺陷，因为只使用部门 Web 站点所依赖的数据库，是很难正常工作的。另一种解决方案似乎能够满足所有的需求。她研究、开发，并创建了一个完整的测试模型来供项目的使用和采用，节约了很多时间。她存取了所有与资产相关联的文件和代码，并下载了一份拷贝便于日后学习。Annie 创建了一个新的过程模型资产，命名为 Claims Processing Model v2.0。详细定义了两个资产之间的关系，这样，当其他人员将来检索这类过程的时候，这些模型会一起查询得到。随着时间的推移，资产之间已定义的关系使得资产的检索变得很容易。

　　活动5：创建需求

　　小结：在这部分场景中，Annie 使用 Rational ClearQuest 沟通并跟踪新索赔处理的需求。Annie 将需求发送给软件架构师 Archie。Archie 对 Claims Processing Model v2.0 资产进行评估，然后使用 Rational Asset Manager 浏览既有的可以重用的 Web 服务。

　　接下来，Annie 使用 Rational Asset Manager 论坛在公司 Web 站点创建新的需求：增加索赔过程的处理。这种论坛类型被映射成 Rational ClearQuest 的需求，然后，当她创建论坛主题的时候，Rational ClearQuest 里会自动地创建相应的新的需求记录。Annie 直接链接到 Claims Processing Model v2.0 资产，这样，架构师就可以轻松地找得到了。

　　软件架构师 Archie 接收到了新需求已经被提交的通知。他打开 Rational ClearQuest 记录并单击链接到 Claims Processing Model v2.0 资产。Rational Asset Manager 打开 Annie 建立的资产描述页。Archie 马上浏览资产的详细信息，并找到包含第一个模型的那个资产。5年前，她曾在国内索赔处理部门协助创建了第一个模型。现在，他再次阅读需求记录并继续评估新的资产。

　　接下来，他使用 Rational Asset Manager 检索能够满足需求的、可被重用的既有服务。在结果列表中，他找到一个全面的资产清单和 WSDL 文件。Archie 用具体的过滤器缩小检索范围，然后，使用 WSDL 记录打开 WebSphere Service Registry 并详细查看解决方案可用的服务。Archie 找到一个 Web 服务资产 FinancialService Implementation v1.0，看起来好像可以派得上用场。当意识到自己在 Web 服务资产所属的 Rational Asset Manager 社区不拥有查看资产的授权，他下载资产并更进一步地查看详细信息。他点击了请求按钮，在几分钟之内，社区管理员已经将他添加进社区，并赋予相应的权限。因为这些解决方案很复杂，Rational Asset Manager 给了公司控制权，来管理谁操作资产，以及 怎样 使用资产。

　　活动6：设计解决方案

　　小结：在这部分场景中，Archie 使用既有的 Web 服务、实施、设计和 Annie 所提供的新模型来创建架构并设计新的索赔处理系统。他使用 Rational Asset Manager 检索既有解决方案，标记新解决方案，然后订阅资产，这样，他就可以监控整个开发过程中的更新。

　　Archie 开始实施解决方案所需的一些服务。从前面创建的两个资产开始： FinancialService Implementation v1.0 和 FinancialService Design v1.0 资产。他打开 Rational Asset Manager 论坛，并向开发团队提问，如何评估既有服务中可能的改进以及潜在的风险。他用合适的索赔处理信息更新资产，提交新的资产 Claims Processing Implementation v1.0 和 Claims Processing Design v1.0。在它们与 FinancialService Implementation 资产之间创建详细的关联。通过 Web 客户端用户接口，Archie 也很快订阅了新的索赔处理资产。他将收到这些资产更新的所有通知。他也用 Corporate Finance 标签给资产作了标记，这样，他就可以根据名字将同类资产分组，下次的检索也就更容易了。

　　当作好设计和创建体系结构的准备时，他打开包含 Rational Asset Manager Eclipse client plug-ins 的 Eclipse 开发环境，通过标签寻找那两个资产。使用 Web 服务，开始创建 Claims Process Website Design v1.0 的架构。接下来，建立与索赔处理资产之间的关联，便于将来的重用。

　　活动7：在整个开发过程中使用 Rational Asset Manager

　　小结：在这部分的场景中，Dave 和他的开发团队为索赔处理创建了解决方案。开发团队使用 Rational ClearCase，但其中的大部分开发活动对于 Rational Asset Manager 是透明的。他们通过论坛讨论开发测试，并在 Rational ClearQuest 中记录了主要 bug。

　　Archie 结束设计工作后，将 Claims Processing Design v1.0 通过 e-mail 发送给开发团队的项目经理 Dave。Dave 链接到Rational Asset Manager 的资产，并仔细查看了资产一步步的历史。他注意到财务服务资产，通过使用 Rational Asset Manager 接口，从 WebSphere Service Registry 评估了 Web 服务，然后从 Rational ClearQuest 执行团队链接到需求。

　　Dave 的团队根据 Archie 设计的具体规定及既有方案来实施新的索赔处理资产。在 Dave 的团队实施 Web 服务并开发支持代码和用户接口之后，就可以对方案进行测试了。Dave 和他的团队成员向 Rational Asset Manager 提交了各种测试用例，称为 Claims Processing Test Suite v1.0 资产。该资产与其它索赔处理资产之间被定义了详细的关联。团队成员使用这些开发测试来发现 bug。一个开发人员发现 Web 站点的索赔处理的记录值出现了错误。他打开 Rational ClearQuest 缺陷报告，发现另一名开发人员 Darnell 之前也曾遇到同样的问题，并将这个资产从CVS当前分支导入到他的工作空间。为了解决这个问题，他在 API 实施了一个新类。然后，他更新了论坛，以便别的开发人员在遇到同样问题的时候会有合理的解决方法。他也更新了索赔处理资产，并在关闭 Rational ClearQuest 缺陷之前，签入 Rational ClearCase。另外，开发团队又使用新的测试用例更新了测试包。

　　活动8：测试并复审资产

　　小结：在这部分场景中，扩充的测试团队、开发人员和主要复审人员通过使用 Rational Asset Manager 测试并审核了资产。在资产被完整测试并接受后，发布工程师修改了 build，这样，新的代码就能够更新到产品中。Annie 完成了最后的测试、检查需求，然后将该资产发送给产品。

　　方案满足了 Rational ClearQuest 需求，Dave 团队对此感到满意，Claims Processing Solution v1.0 资产也已提交到 Rational Asset Manager 以便进一步的审核。来自其它团队的测试人员和开发人员都参与了复审，他们审核资产，直接通过 Rational Asset Manager 论坛向 Rational ClearQuest 记录所有的 bug。主要复审人员是在称为 My Asset Manager 的个性化面板中，通过 e-mail 进行通知的。

　　项目的主要核心成员是 Annie (分析人员)、Archie (架构人员) 和 Dave (主要开发人员)。Annie 首先发现资产并开始审核。团队中的每一员都开始使用测试用例来测试产品。因为资产是在一个完整的测试方案中构建的，这个版本仅作了很小的调整就通过了测试用例的检验。不久，对资产完全审核，所有在 ClearQuest 中打开的缺陷都得到了修正，然后，复审人员认可了该资产。方案通过单元测试之后，发布工程师更新了编译过程，并增加了元数据，表示资产的哪些部分得到了使用。发布工程师为 Claims Processing Solution v1.0 创建了另一个 Rational ClearQuest 记录，并设置了 IT Operations 的状态，以便接收记录并继续布署产品的新服务。Annie 运行了性能和需求测试，以确保 Web 站点的高质量运行。

　　活动9：布署库

　　IT Operations 团队收到 Rational ClearQuest 标示部署库的记录之后，他们从 Rational ClearCase 检索代码，并在公司的 Web 站点部署更新后的 Insurance for Individuals and Families portal。他们把包含公司业务逻辑和服务实施的档案文件布署好，然后依次发布服务接口资产 –- 首先是开发 WSRR (Web service registry and repository) 实例，接下来是测试实例，然后是产品实例。

　　活动10：评估并改进

　　小结：在这部分场景中，执行人员汇总了有关库与资产使用的精确报告，以便于将来的改进工作。

　　在这个 Web 站点开始使用的第一个月中，接听到的服务电话明显减少了。执行团队需要一个创建 Insurance for Families and Individuals portal 方案的内部处理的汇报，以继续实现最佳实践，并对在基于方案的开发环境中的敏捷性进行了评估。Rational Asset Manager 库管理员使用 Rational Asset Manager 的度量和统计能力准备了报告。点击一下，他将数据解压到一个以逗号分隔的文件，然后利用数据在 Microsoft® Excel 中生成一份全面的报告。

　　结果

　　在这个业务场景中，IBM Rational Asset Manager 贯穿于项目的研究、设计、实施、复审和部署和开发各个阶段。管理人员、架构师、开发人员和复审人员共同协作，完成了资产的寻找、复用、更新和测试工作。如果没有 Rational Asset Manager，研究和开发的支出无疑将会很高，尤其是如果没有发现既有模型，那么，费用会更高。

　　此外，IBM Rational Asset Manager 与既有 Rational 软件的集成，极大地扩展和提高了产品的可用性。在不更换或修改 JKE Enterprise 已有任何业务或开发流程的情况下，这一点得到了更充分的体现。

查看本文来源