【IT168 技术文档】
这个由两部分组成的系列介绍了ClearQuest中的ALM的概念和设计目标。本文是第1部分，我们将介绍使用Rational ClearQuest和ALM包作为您的变更管理（CM）解决方案的好处，并展示ClearQuest中的ALM的概念和设计目标。
贯穿应用程序生命周期管理变更
根据治理、安全、所有权和全球分布开发（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中描述的建立安全的步骤如下：
- 创建用户和组。已有的ClearQuest部署已经具有了用户和组。使用这些组定义来定于安全策略。对于新的ClearQuest部署，参考ClearQuest文档来创建用户和组。
- 创建安全策略。安全策略的使用是设计中的基础概念。安全策略被创建来定义哪些用户能够访问项目。一种简单的方法是添加一个或者多个ClearQuest组到一个安全策略记录。对于一些组织，对项目访问控制也许不是一个重要问题。如果是这种情况，您可以简单的创建一个安全策略，将所有的ClearQuest组加到这个安全策略中。这个安全策略授权每一个人都可以访问项目。如果对项目的访问是您所关注的，那么您应该创建一个安全策略来控制一定的组能够访问项目。例如，一个组织使用第三方的提供商，那么为这个提供商的用户创建一个安全策略，这样将限制他们仅仅能够访问赋予他们权限的项目。
- 选择安全策略。当您创建一个项目时，安全策略是从下来列表中选择的。管理员能够定于安全策略，并授权项目经理选择对于他们的项目最好的安全策略。一个安全策略能够被一个或者多个项目使用。安全是在项目级别设置的，所有的记录都是项目相关的。在创建项目时，安全策略是必填选项。
- 创建角色标签。角色被用来定义哪些用户和组能够执行哪些动作。很多时候一个组织有一个角色名的列表，比如，分析人员、开发人员、架构师和测试人员。您通过创建一个ALMRoleLabel记录来定义角色。
- 为项目创建角色。而角色标签可以在企业的范围内共享，角色定义可以根据项目的不同而不同。。每个项目决定哪些角色被包括，哪些用户执行什么动作。通过创建ALMRole记录定义新的角色。
项目识别与唯一性
随着时间的迁移，项目的数量也将变大。项目的唯一性和识别特性被需要来识别特定的项目。此外，大型的项目可能被分解成多个小项目，并共享相同的发布版本。类别被用来对项目进行分类，发布被用来识别软件项目的版本。图6展示了与识别和划分项目相关的记录。
图6: 类别和发布定义项目的唯一性
图6的步骤如下：
- 创建类别树来分类项目。项目通过类别进行识别，这帮助划分产品、特性或者项目交付的组件。在一些组织中，有可能需要创建多于一个的类别树。例如，一个单一的组织可能使用一些产品和服务的组合来识别项目。类别类型被用来识别类别模式。例如，使用项目的例子，两个CategoryType记录被创建，一个类别类型被定义，您能为类型创建类别。类别可以是层次化的。首先创建CategoryType，然后为类型创建类别。
- 创建发布标签。一个发布识别软件的版本。很多组织为发布标签标准化命名规则。ALM解决方案通过提供Release Label记录支持这种需求。
- 选择类别。当创建一个项目记录时，可用的类别出现在下拉列表中。选择一个类别。
- 选择发布。当创建一个项目时，可用的发布标签出现在下拉列表中。
例如，本文描述的ALM模式，它作为ClearQuest 7.1.0.0的一部分被提供。为了管理它，我们创建一个名为“Outof 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中的步骤描述如下：
- 项目能够被划分成阶段和迭代，比如，计划，时间间隔典型的以周为单位。例如，IBM Rational Unified Process，或者RUP，定义了四个阶段：启始、精化、构建和产品化。另一个例子是，4D（定义、设计、开发和交付）。通过定义阶段和迭代标签来开始。例如，首先构建迭代可以被标记为C1（代表构建迭代1）
- 创建Phase记录当创建这些记录时，选择一个Phase标签和项目。如图10所示。为您的项目的每个阶段创建一个Phase记录。
图10: 创建一个Phase记录，为"Out of Box ALM"项目定义一个"Construction"阶段。
- 创建Iteration记录。一个阶段被划分成多个迭代。迭代关注于团队的交付增量。通过Plans标签页浏览项目的阶段和迭代。这些是可选的。
RUP的用户将针对启始、精化、构建和产品化创建Phase记录。Iteration记录使用例如“I1”的名字，代表启始阶段的第一个迭代，“C1”代表构建阶段的第一个迭代。
敏捷用户可以使用不同的阶段和迭代的名字。一个方法是创建一个单一的阶段记录，名字为“Iteration”。接下来，创建一个迭代记录，使用迭代号命名。例如，创建迭代记录，然后命名为“1”和“2”，依此类推。当使用系统时，您将使用“Iteration 1”、“Iteration 2”……。
系统是足够灵活的允许小的团队管理迭代，也允许扩展成更大规模的团队，他们使用更加正式的阶段和迭代。不是所有的团队都使用迭代开发，因此，阶段和迭代的使用是可选的。因为迭代开发是软件开发的非常好的实践，所以记录作为解决方案的一部分被提供。
项目模板
就像您在之前的项目的主题中看到的那样，有几种记录类型与设置项目有关。这部分将介绍流线型项目创建的新特性。
复制项目
很多时候，新项目于以往的项目是相似的。例如，相同项目的下一个版本与之前的项目有很多相同的特征，或者子项目与主项目有很多相同的特征。“复制”一个已存在项目的能力被引入到了ALM解决方案中。“复制项目”命令复制项目的结构，例如，角色定义，阶段和迭代，工作配置。它不复制数据，例如，特定的请求、任务或者活动记录。一旦您有了一个副本，您就可以根据您的需要进行修改。
您能允许项目经理复制任何项目，或者您能建立一个非常好的实践的项目模板。通过设置样例项目，带有所期望的设置，您可以向您的项目经理提供指导。例如，您的组织也许有很多项目，这些项目实施一个成品应用，比如SAP。在另一方面，您的面向服务的体系架构（SOA）项目很可能是截然不同的。您可以创建一个样例SAP项目，和一个样例SOA项目，下一次有类似的项目是，就可以复制样例项目。
项目向导
项目向导以一个基于Web的用户界面被提供，将指导您进行设置选择。向导提供了记录列表来创建项目。项目的创建包括不止简单的创建一个项目记录。这里有一个为团队建立项目上下文环境的过程。这与在线购买航空机票非常类似。购买航空机票的动作包括查许航班、选择舱位等级和购买机票。接下来是选择座位和办理登机手续。在您购买机票之前和之后都有有些动作。创建项目也有同样的过程。
向导和项目复制能力一起提供了强大的快速创建新项目的方法，同时确保了项目之间的设置的一致性。
