实例解说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 站点所依赖的数据库