本概览介绍了 IBM Rational ClearQuest 这一开箱即用（out-of-the-box）的应用生命周期管理（Application Lifecycle Management, ALM）解决方案背后的理念和设计目标，并展示了使用 ClearQuest 和相关的 ALM 工具包作为变更管理（Change Management, CM）解决方案带来的好处。本文是由两篇文章组成的系列的第 1 部分，介绍 ClearQuest 中 ALM 的概念和设计目标。

 这个由两部分组成的系列介绍了 ClearQuest 中的 ALM 的概念和设计目标。本文是第 1 部分，我们将介绍使用 Rational ClearQuest 和 ALM 包作为您的变更管理（CM）解决方案的好处，并展示 ClearQuest 中的 ALM 的概念和设计目标。

下个月的第 2 部分中，我们将描述 ClearQuest ALM 解决方案的详细内容，并展示 ALM 基于角色的用户体验的概念，它被应用在 IBM Rational 产品开发场景的变更管理中，以及 ClearQuest 客户的使用场景中。

贯穿应用程序生命周期管理变更

根据治理、安全、所有权和全球分布开发（GDD）来管理复杂度，也包括 ALM，产生了对管理变更的需求。使用 CM 软件工具，比如 ClearQuest，围绕着工具能够提供的良好的利益定义过程，能够帮助连接并协调开发组织中的不同的小组或者团队，无论他们所有人是否在一个办公地点，或者是分布在世界各地。

就像图 1 所示，ALM 的基本前提是在项目中跨越多个团队为开发软件建立过程，从而管理项目的所有内容，这些内容由每个角色通过他们的方式长生。团队成员依赖五种类别的能力来支持他们的开发工作。他们需要 1)协作；2）确保他们的工作成果能够被追踪到原始的请求；3）自动化非创新性的、可重复的任务；4）寻找持续改进的策略；5）如果团队是不同地域分布的，他们需要一个软件交付链的闭合连接。

图 1: ALM 配合的开发活动以生成软件结果的资产。

例如，一个单一的软件需求能够影响一个应用的设计、开发、构建和测试，如图2 所示。每个软件开发过程中的角色会产生一些对需求的设计、实现和测试有贡献的内容。理解和管理满足每一个需求相关工作的数量对于一个团队能够按时、在预算内交付软件是至关重要的。

图 2: 一个单一的需求 (新的需求) 能够影响到开发团队中的每一个成员。

项目经理需要有信心所有的需求将被实现和测试，并在交付之前具备良好的质量。对于软件开发团队的挑战不在于创建一个单一的工件（源代码、需求或者测试），而是理解工件之间的关系。

ClearQuest 应用程序生命周期管理

Rational ClearQuest 7.1.0.0 包含了打包好的 ALM 解决方案，提供了对于管理 GDD 和 ALM 挑战的很多支持。 ALM 包提供了流线型进和敏捷应用开发过程的支持，这两种开发过程都是基于角色和过程驱动的，如图 3 所示。项目为完成的工作定义了上下文关系，并能够通过安全的设置策略和角色定义确保安全。工作能够被分配给团队的成员，他们可能是在同一办公地方，也可能分布在不同地域。工作能够被追溯到原始的请求，以及项目中对请求的实现。 　

图 3: ClearQuest ALM 支持基于角色的开发过程

概述与设计目标

ALM 模式提供了一系列的关联记录，能够帮助团队管理软件开发项目。ALM 模式（和包）被设计并构建来提供下面的好处：

• 对所有新的和已有的 ClearQuest 客户都有用
• 提供可从小型团队到企业范围的组织可扩展的解决方案
• 支持全球分布式开发团队。支持，但不要求多站点和 UCM
• 带有一系列包和模式的 ClearQuest v7.1 交付。 ALM 包能够被应用到 ClearQuest 7.0.1。
• 降低客户的所有权成本并改进投资回报率
• 提供至少 70% 的现成功能
• 减少至少 50％ 的部署时间
• 减少管理变更的数量以支持企业用户
• 授权项目经理和团队领导在不影响模式的情况下配置项目
• 为启动提供基本的“构建模块”
• 提供 ALM 的“最佳实践”的经验，您可以直接使用，或者扩展并应用到现有的 ClearQuest 实现上
• 提供安全的基于角色活动的项目环境
• 促进团队在整个软件开发生命周期内的协作
• 简化支持法规遵循和审计的能力
• 提供现成的样例数据库，展示对 OpenUP 过程和 Eclipse Process Framework 的支持

ALM 模式的规程角色将帮助团队管理交付软件项目相关的工作。ALM 模式也提供有用的构建模块和框架，使客户化配置更加容易以适合每一个企业。

核心概念

以下是 ClearQuest 中使用 ALM 模式是需要理解的三个基本概念：

• 项目通过了对于管理团队成员工作的上下文环境。通过安全策略，用户被授权访问项目，他们的活动是通过他们的角色定义的。
• 管理工作能够以请求、任务和 活动来实现。活动和任务的定义被过程定义驱动，过程定义根据项目的不同而不同。
• 针对项目和管理工作，系统范围的设置能够被定义。这些设置允许重用，并在多项目之间保持一致，同时也能够应用到企业范围。这典型的包括了一次设置，或者根据团队的成长进行小的调整，从而逐步的发展系统的使用。

本文余下的内容将描述这些基本概念中的第一个，项目如何为工作提供基于角色上下文环境。第二和第三个概念将在第 2 部分描述。

项目如何为工作提供基于角色上下文环境

所有在 ALM 模式中的工作被一个项目进行组织。项目提供了上下文环境，访问控制和基于角色的安全模式。项目管理知识体系（PMBOK）将项目定义为一个临时的为创建一个唯一的产品、服务或者结果的活动集合。在 ALM 系统中，项目是这样一个环境，在这里哪一个工作被做，并提供在软件项目生命周期中对完成工作的可跟踪性。图 4 显示了 ALM 项目的架构，包括组成一个项目定义的对象，系统范围的设置和已存在的 ClearQuest 用户和组的管理。

图 4: 项目的概念化概要。所有 ALM 模式中的工作通过一个项目进行组织。

这部分余下的内容将描述用于定于项目的记录。

项目安全

安全是所有项目工作中的重要方面。在 ALM 模式中，项目安全是通过谁访问项目，他们能做什么来定义的。图 5 展示了在定义安全策略和角色时相关的记录类型。

图 5: 安全策略提供访问权限，角色定义允许操作

图 5 中描述的建立安全的步骤如下：

1. 创建用户和组。已有的 ClearQuest 部署已经具有了用户和组。使用这些组定义来定于安全策略。对于新的 ClearQuest 部署，参考 ClearQuest 文档来创建用户和组。
2. 创建安全策略。安全策略的使用是设计中的基础概念。安全策略被创建来定义哪些用户能够访问项目。一种简单的方法是添加一个或者多个 ClearQuest 组到一个安全策略记录。对于一些组织，对项目访问控制也许不是一个重要问题。如果是这种情况，您可以简单的创建一个安全策略，将所有的 ClearQuest 组加到这个安全策略中。这个安全策略授权每一个人都可以访问项目。如果对项目的访问是您所关注的，那么您应该创建一个安全策略来控制一定的组能够访问项目。例如，一个组织使用第三方的提供商，那么为这个提供商的用户创建一个安全策略，这样将限制他们仅仅能够访问赋予他们权限的项目。
3. 选择安全策略。当您创建一个项目时，安全策略是从下来列表中选择的。管理员能够定于安全策略，并授权项目经理选择对于他们的项目最好的安全策略。一个安全策略能够被一个或者多个项目使用。安全是在项目级别设置的，所有的记录都是项目相关的。在创建项目时，安全策略是必填选项。
4. 创建角色标签。角色被用来定义哪些用户和组能够执行哪些动作。很多时候一个组织有一个角色名的列表，比如，分析人员、开发人员、架构师和测试人员。您通过创建一个 ALMRoleLabel 记录来定义角色。
5. 为项目创建角色。而角色标签可以在企业的范围内共享，角色定义可以根据项目的不同而不同。。每个项目决定哪些角色被包括，哪些用户执行什么动作。通过创建 ALMRole 记录定义新的角色。

项目识别与唯一性

随着时间的迁移，项目的数量也将变大。项目的唯一性和识别特性被需要来识别特定的项目。此外，大型的项目可能被分解成多个小项目，并共享相同的发布版本。类别被用来对项目进行分类，发布被用来识别软件项目的版本。图 6 展示了与识别和划分项目相关的记录。

图 6: 类别和发布定义项目的唯一性

图 6 的步骤如下：

1. 创建类别树来分类项目。项目通过类别进行识别，这帮助划分产品、特性或者项目交付的组件。在一些组织中，有可能需要创建多于一个的类别树。例如，一个单一的组织可能使用一些产品和服务的组合来识别项目。类别类型被用来识别类别模式。例如，使用项目的例子，两个 CategoryType 记录被创建，一个类别类型被定义，您能为类型创建类别。类别可以是层次化的。首先创建 CategoryType，然后为类型创建类别。
2. 创建发布标签。一个发布识别软件的版本。很多组织为发布标签标准化命名规则。 ALM 解决方案通过提供 Release Label 记录支持这种需求。
3. 选择类别。当创建一个项目记录时，可用的类别出现在下拉列表中。选择一个类别。
4. 选择发布。当创建一个项目时，可用的发布标签出现在下拉列表中。

例如，本文描述的 ALM 模式，它作为 ClearQuest 7.1.0.0 的一部分被提供。为了管理它，我们创建一个名为“Out of Box ALM”的项目，设置 Category 为 “ALM”，并设置 Release 为“7.1.0.0”，如图7。这三个识别符能够仅仅标识 ALM Release 7.1.0.0 项目。一个后续的项目例子能够保留每一件事情都相同，除了变更 Release 到 “7.2.0.0”。

图 7: 创建项目记录。三个识别符 —— name、category 和 release —— 定义项目唯一性。

项目之间通常具有关联。这些关联能够在 Related Projects 标签页中建立，如图 8。

图 8: 一个项目与它的子项目和父项目

就像之前提到的，一个大型的项目通过被分解成多个小项目。为了建议起项目之间的关系，您能够使用 Super Projects 和 Sub Projects 域。此外，一个单一的软件解决方案可能经历多个修订版本。您可以使用 Prior Project 或者 Next Project 管理这些关系。

项目计划

成功的软件项目创建和交付包含了为完成工作的计划。迭代开发技术已经被证明在计划和交付软件项目上是成功的。图 9 显示项目计划记录的使用来定义迭代项目。

图 9: 针对迭代、增量软件开发的项目计划

图 9 中的步骤描述如下：

1. 项目能够被划分成阶段和迭代，比如，计划，时间间隔典型的以周为单位。例如，IBM Rational Unified Process®, 或者 RUP®，定义了四个阶段：启始、精化、构建和产品化。另一个例子是，4D（定义、设计、开发和交付）。通过定义阶段和迭代标签来开始。例如，首先构建迭代可以被标记为 C1 （代表构建迭代1）
2. 创建 Phase 记录当创建这些记录时，选择一个 Phase 标签和项目。如图 10 所示。为您的项目的每个阶段创建一个 Phase 记录。

图 10: 创建一个 Phase 记录，为 "Out of Box ALM" 项目定义一个 "Construction" 阶段。

3. 创建 Iteration 记录。一个阶段被划分成多个迭代。迭代关注于团队的交付增量。通过 Plans 标签页浏览项目的阶段和迭代。这些是可选的。

RUP 的用户将针对启始、精化、构建和产品化创建 Phase 记录。Iteration 记录使用例如“I1”的名字，代表启始阶段的第一个迭代，“C1”代表构建阶段的第一个迭代。

敏捷用户可以使用不同的阶段和迭代的名字。一个方法是创建一个单一的阶段记录，名字为“Iteration”。接下来，创建一个迭代记录，使用迭代号命名。例如，创建迭代记录，然后命名为“1”和“2”，依此类推。当使用系统时，您将使用 “Iteration 1”、 “Iteration 2”……。

系统是足够灵活的允许小的团队管理迭代，也允许扩展成更大规模的团队，他们使用更加正式的阶段和迭代。不是所有的团队都使用迭代开发，因此，阶段和迭代的使用是可选的。因为迭代开发是软件开发的最佳实践，所以记录作为解决方案的一部分被提供。

项目模板

就像您在之前的项目的主题中看到的那样，有几种记录类型与设置项目有关。这部分将介绍流线型项目创建的新特性。

复制项目

很多时候，新项目于以往的项目是相似的。例如，相同项目的下一个版本与之前的项目有很多相同的特征，或者子项目与主项目有很多相同的特征。“复制”一个已存在项目的能力被引入到了 ALM 解决方案中。“复制项目”命令复制项目的结构，例如，角色定义，阶段和迭代，工作配置。它不复制数据，例如，特定的请求、任务或者活动记录。一旦您有了一个副本，您就可以根据您的需要进行修改。

您能允许项目经理复制任何项目，或者您能建立一个最佳实践的项目模板。通过设置样例项目，带有所期望的设置，您可以向您的项目经理提供指导。例如，您的组织也许有很多项目，这些项目实施一个成品应用，比如 SAP。在另一方面，您的面向服务的体系架构（SOA）项目很可能是截然不同的。您可以创建一个样例 SAP 项目，和一个样例 SOA 项目，下一次有类似的项目是，就可以复制样例项目。

项目向导

项目向导以一个基于 Web 的用户界面被提供，将指导您进行设置选择。向导提供了记录列表来创建项目。项目的创建包括不止简单的创建一个项目记录。这里有一个为团队建立项目上下文环境的过程。这与在线购买航空机票非常类似。购买航空机票的动作包括查许航班、选择舱位等级和购买机票。接下来是选择座位和办理登机手续。在您购买机票之前和之后都有有些动作。创建项目也有同样的过程。

向导和项目复制能力一起提供了强大的快速创建新项目的方法，同时确保了项目之间的设置的一致性。

接下来的第 2 部分

下个月，我们将结束这个系列文章。我将描述剩下两个 ALM 模式中的基本概念－管理工作，管理及安全。

致谢

特别感谢很多为本文贡献实践和精力的人。按字母顺序：Kenneth Giffels, Robert W. Myers, Michael J. Saylor, Rick Weaver。

参考资料

• 参与论坛讨论。
• 您可以参阅本文在 develperWorks 全球网站上的 英文原文。
• 现在开办了一个特别为 Rational Edge 的文章创办的 新论坛，现在您就可以分享您对本文或本期杂志或以前杂志中的其他文章的想法。阅读世界各地您的同行们所说的内容，生成您自己的讨论，或者加入正在进行的讨论。单击 这里 开始。
• 全球 Rational 用户组社区

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号