| UML软件工程组织 | |||
| |
|||
|
|||
使用 ClearQuest 7.1.0.0 进行应用程序生命周期管理，第
2 部分
2008-08-15 作者：Carolyn Pampino,Robert
Pierce 来源：IBM
这篇文章是 IBM Rational ClearQuest 的打开即用的应用软件生命周期 (Application Lifecycle Management, ALM) 解决方案背后的一些概念和设计目标的概述，文章描述了将 ClearQuest 和 ALM 包作为您的变更管理 (Change Management, CM) 解决方案来使用的好处。这个由三部分组成系列的第 2 部分文章，讨论了在 ALM 环境中管理工作的问题。 这个有三部分的组成的文章呈现了 IBM®Rational®ClearQuest®的打开即用的应用软件生命周期 (ALM) 解决方案背后的一些概念和设计目标的概述。 上个月，在 第 1 部分 中，我们讨论了将 ClearQuest 和 ALM 包作为您的变更管理 (CM) 解决方案来使用的好处，并提出了 ClearQuest 中 ALM 的概念和设计目标。 这个月在第 2 部分中，我们将详细描述 ClearQuest ALM 解决方案，并展现 ALM 基于角色用户经验的概念，它可以将两者应用到 IBM Rational 产品开发中的变更管理中，以及应用到 ClearQuest 客户使用情景中。下个月，我们将通过阐述如何把 ClearQuest ALM 和您当前的工具以及流程整合起来，为这篇文章做个总结，比如 IBM Rational RequisitePro®，我们将涵盖一些能够帮助您开始的建议。 管理工作项目为我们的工作设置环境；而我们必须完成这个项目。在软件解决方案开发的整个过程中，许多行为需要被执行，从而确保所以的工作都已经完成。这项工作记录包含在 ALMWork 包中，提供了一种跟踪此开发循环中您的小组需要处理的请求和任务的方法。在 ClearQuest 先前版本中，必须通过为每个被管理(缺陷、 变更请求，等等。)的条目创建记录类型的方式来管理工作。然而，在 ALM 模式中，关注的焦点却是小组成员工作的分配。ALM 模式为管理工作提供了主要的记录类型，称作：请求、任务，以及活动。
这三个记录类型中的任何一个，它们自己都可以被分配“类型”（将在下面进行讨论）来进一步改进工作的本质。 除了工作分配之外，通常还有些关于工作的问题或者评论。因此，还会提供一个注释记录：
图 1 描述了请求、任务、活动，以及工作类型之间的关系。 
图 1：主要的 Work 记录。请求定义了“需求”以及它被“找到”的位置。任务定义这个工作需要完成这个项目的请求。活动则被分配到个体并共同完成这个任务。Work 类型鉴定这个工作的本质。 所有的工作以请求 的一些形式开始。而请求 则描述了需求，并由这个项目中的任何一个利益关系者所拥有，任务和活动是跟踪这些工作的记录，为了解决这个请求，这些工作已经被分配而且必须完成。这样就允许您比较请求的数目以及委托任务的数量。这样还可以使项目经理查看每个请求包含多少工作量，以及工作量的完成或者未完成的情况。此外，还有些时候一个请求可能影响到更多的项目。这种工作请求的分离以及实现这些工作的承诺允许每个被影响的项目来管理这个任务，因为它与满足具体项目环境中的 请求 密切相关。 
图 2： 使用这些 Work 记录。筛选这些请求；并为这些项目创建任务。活动完成这些任务，它是可以修改的，并且请求是处于封闭状态的。 图 2 进一步描述了与这些新记录类型一起工作的流程。每个箭头都代表记录之间的父/子的关系。
请求记录是起初工作的起始点。任何利益相关者都可以提出请求， 周期核查它的状态，以及对任何问题或者评论的回应。这个模式的用户优先设置决定谁（也就是用户、组，或者角色）可以提交新请求，如图 3 所示。一个请求：
图 3：一个新请求记录 图 3中显示的某些区域是强制性的。当“项目建立在……”的选项已被设定后，历史标签上的安全部分就会自动设定到那个项目。Headline、Type，以及 Severity 都是左边请求需求所需的。 这个请求的状态转换如下所示，十分简单。这个请求要么是完整的要么不是，正如图 4所描述的那样。 
图 4： 请求记录的流程 请求可以是孤立的或者被拒绝的。一旦处于孤立或者被拒绝状态，它可以重新被打开。任务在一个项目的环境下实现请求。 这种请求分类的方法为密集的团队提供了明显的指示。这个小组评审这个请求并确定是否以及什么时候可以处理它。如果这个请求 将在一个特定项目中被处理，那么就要为这个特定的项目创建一个任务，并与这个请求联合在一起，如图 5 所示。任何查看这个请求 的人都能发现需要哪些任务来实现它。任何查看这个任务的人都能看到哪个请求将要去完成。 一个任务：
图 5： 如果这个请求将在特定的项目中被编址，那么就要为与这个 请求 联合在一起的项目创建一个任务。 有些区域是强制性的，如图 5所显示的那样。当“项目assigned to”被设定以后，历史标签上的这个角色和安全部分就会自动设置为那个项目。Headline、Type、Severity， 以及相关的请求 (在 Related Records 标签) 都在请求区域的左边。 
图 6：一个任务的流程 这个任务的状态转变非常简单，如图 6 所示。一个可能是 Opened、Activated，或者 Completed。当一个任务已经被提交，那么它就会处于 Open 状态。激活一个任务表明这个工作已经开始。任务可以重新被打开。 这个小组领导查看一个任务来决定需要什么样的活动来完成这个任务。通常一个单一的任务需要多个用户来完成。创建一个活动并到单个的小组成员，来完成一个离散的工作单元，如图 7所示。一个活动：
图 7： 创建一个活动并将它分配到单个的小组成员来完成一个离散的工作单元 图 7中显示的某些区域是强制性的。Headline、Type、Severity， 以及相关的任务（在 Related Records 标签上）都在左边请求区域中。History 标签上的这个 Security Context 是从相关的任务继承而来的。活动还有一个简单的状态转变，如图 8所示。在这种情况下，有四个状态，正如 UCM 有四个状态一样。活动是 Submitted、Opened、Activated，以及 Completed。一个行为可以从 提交的状态中 Activated。 
图 8：活动有一个简单的状态迁移 有一个重要的环境转变值得注意。在 ClearQuest 的先前版本中，记录是用来获取所有的区域信息，以及利用状态转换将这个记录在整个过程中“移动”。在某些情况下，这个状态转换还包括将这个记录的所有权交还给一个新的小组成员。实际上，每个状态都可以设置代表这个小组中一个成员单一的工作单元。（这仍然在产品中操作并且继续被支持。） 这个 ALM 解决方案提供了一个可选择的方法。要描述这个转变，我们拿一个“缺陷”作为例子。 在 ClearQuest 的先前版本中，缺陷记录是用来管理系统中发现的所有缺陷的 (请看图 9)。这个缺陷记录将有一个状态变更的设置。例如，第一个状态可能是“Develop”，并且被分配给一个开发人员。下一个状态可能是 “Validate”，分配给一个测试人员。 
图 9： 状态转变以及现存的 ClearQuest 记录 当这个开发人员完成她的工作以后， 缺陷记录就会转换到下一个状态，从而导致这个记录将的所有权变更为测试人员。这个模式将一直工作到您拥有两个分离的小组为止，而且每个小组都需要一个不同设置的状态转换。然后呢？您有三种选择：为第二小组创建一个新记录类型，修改现存缺陷记录类型的状态转换，并使每个人都完全附和，或者忽视这个请求。利用这个 ALM 计划，这个模式就可以进行变更（请看图 10）。这个新模式以一个缺陷类型的请求 开始。所有的小组都可以使用这个记录类型。它拥有一个简单的状态转换模式，并且只是用来获取关于缺陷和所发现这个项目位置的信息。 接下来，您要创建一个任务，并决定将由哪个 项目来完成这个任务。 项目中的这个部分将确定可利用的任务类型。选择一个任务类型，并将决定用来实现它的行为的设定。 
图 10： 用活动取代状态转变 不是利用复杂的状态转换图表将一个单一的记录通过多个用户的设置来移动，利用这种方法，您可以简单地创建一个活动设置。因为任务和活动是在各个项目地基础上配置的，ClearQuest Administrators 不再需要为项目小组的每个过程变异请求而修改模式。这个项目的领导者可以简单地配置活动设置，他们希望完成每个任务类型。（请看下面关于在类型基础上配置任务和行为的信息。） 正如上面所述，请求、任务， 以及活动可以进一步利用定义这个工作性质的“Type”属性来修改。例如，您可能拥有一个带有“Defect”类型属性的请求，“Fix Defect”类型的任务，以及一个有 “Implement” 或者 “Test” 类型属性的活动。 工作类型定义是可自定义的，而且在系统范围内都是有效的。定义这个工作类型只是一个简单地创建一个新 ALM 类型记录的问题。
图 11： ALM类型Record
一旦您定义了类型，您就可以利用下面所讨论的 ALMWorkConfiguration 将这些类型捆绑到一个项目上。 ALMTypes 和 TypeLabels 授权予您来为您的环境创建一个高度自定义化系统。如果您的组织对过程有一定的标准，比如 RUP 或者 IT Infrastructure Library (ITIL®) ，您可以将这些词汇引荐到您的类型定义中。 但是我们说您仅仅是想要一个大概的方法来管理您团队的工作。或者感觉这个定义的三个水平的观念您已经准备好去使用了，而且您仅仅是想要将这个工作分配到个人，并去完成它。有些“敏捷”小组是以这样方式来工作的。 您可以按照以下方法创建一个几乎最小的方法，创建一个叫做 “General”的 类型 Label ，为请求、任务、以及活动创建 类型，所有的类型为 General。如果您想突出它们，可以创建额外的活动类型。
图 12： 单一的一个任务可以使活动聚集，从而创建一个敏捷灵巧的模式。
图 13： 添加请求 和任务作为这个项目的默认项
在这个例子中，所有的工作都是由活动管理的。这些活动像一个工作队列，工作在这里被分配和完成。您将拥有许多这个项目的活动，但是只有一个任务和一个请求。这个项目的所有用户都将了解并影响活动；然而，他们还需要了解任务或者请求。 这种方法可以应用在小型的，敏捷小组，短暂的项目，这里的小组成员只想了解“我要做什么样的工作？”然而，对于大规模被捆绑有常规请求的企业，这个模式可能就不能满足，正如您不能跟踪所有的工作到最初的请求一样。 请求、任务，以及活动的缺口创建了一个功能强大的新模式。然而 ，在先前的 ClearQuest 模式中，使用了多种记录类型来定义详细的状态转换。实际上，过程可能是由这个记录类型和它的状态来管理的。接下来的问题就变成：我如何以这种新的模式管理这样的过程？ 第二个值得关心的问题包括必须为每个请求手工创建任何和行为。 在最初的模式中，您仅仅创建了一个记录，状态就随之而来。在这个新模式中，一个单一的行为代表一个状态变更。那样假定创建了大量的行为，但是您如何才能保证在每个时间都使用了相同的行为了？ 进入 Work Configuration 记录，如图 14所描述的那样。这里讲述的是新模式的灵活性是怎样在操作中实现的。要调节每个项目小组的工作流程，您现在可以配置活动的默认设置，这需要完成每个项目的任务。项目和/或者过程管理者将是对理解这个记录最感兴趣的人。这个小组的其他用户不需要了解。 
图 14： Work Types 定义了这个工作的性质， Work Configuration 定义了一个被推荐的过程。 定义一个 Work Configuration：
Work Configuration 允许项目经理在各个项目的基础上建立自定义的工作管理过程。这里用一个例子做了最好的解释，因此让我们继续利用我们上面开始的缺陷例子。 项目 'A' 拥有一个 “Problem”类型的请求。这个项目的 Work Configurations (显示在图15中) 如下所示：
图 15：用两个项目，两个过程来确定一个问题。这里您用项目定义的行为设置来取代一成不变的状态转换。 如图 15进一步描述的，在 项目B 上您可以配置一个行为的不同设置，从而坚持小组的工作方式。这个项目的工作配置如下所示：
还应该注意的是图 15描述了拥有一个单一请求的能力，这个请求由两个不同的任务在两个不同的项目中处理的。这样就允许了并行开发，每个项目小组就可以在它们自己的项目环境中为满足这个请求而分配和跟踪工作。 图 16显示了16 项目 Team B 所需的 Work Configurations： 
图 16： Work Configurations 是用来管理一个缺陷的。一个请求类型可能需要任务的特殊类型，它拥有它自己的行为设置。工作配置为项目定义这些过程政策。 我们仅仅向您展示了一个例子；然而，Work Configurations 潜在的使用环境是无穷无尽的。例如，您可以为 一个项目创建一个任务。这个任务可能拥有一些活动，比如“定义角色”、“找到团队成员”、“定义迭代”等等。另一个任务可能包括需求的详细说明，并附有编写用例，定义性能基准点的个人行为，等等。 Work Configuration 允许 项目经理在各个项目的基础上建立过程。“OpenUP” (将在下面讨论)的 ALM 样本数据库描述了 Work Configurations 是如何被用来 OpenUP 过程的。 每次修改这个源代码时，这个应用软件就会被构建并被证实有足够好的品质开始进行测试。一旦被证实，这个构建就会“部署”到测试的测试服务器。这个交付源代码的方式改变，就会构建应用软件，无论范围和释放的大小，无论它是一个绿色区域应用软件，一个现存应用软件的主要修订，一个补丁或者一个漏洞，都会进行测试。当找到错误后，缺陷就会被记录到日志，源代码也会被修改，从而修复这个缺陷。这个应用软件必须重新被构建并部署到测试服务器上为测试所用。通常，了解要测试哪个构建就是由“系统知识”来决定的——您要知道适当的人群要了解使用哪个构建。 ALM 模式支持工作流程模式，在这个流程模式中会发生迭代，并行开发以及测试。开发人员在他们从事以及完成 Development 行为后会交付变更。释放工程师创建基线、运行构建，以及验证和促进构建。测试人员从事并完成 Test 行为。 在软件开发项目中，总会不断地出现构建。对于开发小组常见地问题是：“在构建中要应用什么？”以及“在构建中要测试什么？”这个 ALM 解决方案包括构建记录，它被引入作为构建以及 ClearQuest 7.0.0.0 中的 Deployment 包中的一部分。这样允许这个小组获取关于每个构建的信息。此外， ALM 解决方案利用基线记录 (请看图 17) 来跟踪在每个构建中交付了什么行为。基线、构建，以及活动记录的使用可以让测试人员了解测试什么，以及跟踪哪些测试已经在这个构建中运行。 
图 17：基线记录与 UCM 的整合 基本流程如下所示：当释放工程师管理这个构建时，就拥有获取哪个开发行为已经被完成的机会。关键是鉴定从最后的构建以来哪些行为已经被交付。基线是用来获取特定时间行为的状态的。这对 UCM 来说通常会识别“基线”名词以及它与获取任何时间点源代码版本的联合。ClearQuest ALM 解决方案为 ClearQuest 引人了一个基线记录，它可以用在到 UCM 基线的映射中。当在 UCM 创建了一个基线，就可以采用这些行为的“差异器”，鉴定哪些是新的行为。这个行为列表可以在 基线记录中组成，如图 18所示。对于非－UCM 用户，ClearQuest 问题用来鉴定这个列表中的行为，它们可以被手工添加到 基线记录中。 
图 18：构建记录包括完整的活动 一旦采用了基线，这个构建就会被执行。构建记录（参见图 19）是用来获取这个构建的状态的。从这个记录中您可以创建一个 基线记录的参考标准。这样将这个基线与构建测试连接在一起。这个构建的状态在构建记录本身上传达。小组的剩余部分可以利用这些记录来定义他们接下来行为的流程。对于已经通过的构建，测试小组可以审核构建记录和完整行为的设置。每个行为都包括一个可以回到最初任务的连接，还可能包括测试行为。将这个新可视性嵌在这个构建内容中，测试人员就可以聪明地关注他们的测试工作。 
图 19： 带有新 ALM 标签的构建记录 看第一眼，听起来像花费了很大精力。然而，有了构建脚本和构建自动化操作，大量工作都可以作为这个构建的一部分自动完成。一个 Perl 脚本提供两个基线的“差速器”，并构成一个基线记录。另一个 Perl 脚本则创建和构成 BTBuild 记录。最好的实践是将构建的创建和 基线记录合并到您的脚本中或者 IBM Rational Build Forge® 项目中。当运行这个构建时，利用提供的 Perl 脚本自动创建 Baseline，并确定行为，然后在 ClearQuest 中创建构建记录，用这个构建的相关信息构成这个区域。 任务可以被分配到这个项目的迭代中。这样允许项目小组平衡他们的在迭代中的工作量。此外，可以创建像图 20中的图表来看这个工作是如何分配到小组中的。 这种洞察力帮助项目经理 在小组成员中均衡地分配工作量，从而避免了“关键路径”的情景。这样的图表还可以帮助项目经理确保所有的工作被分配。 
图 20：管理工作量的图表 在图 20中，要注意在 “No value”一栏中有五个任务。这表明它们没有被分配，可以像 项目经理的触发器一样，有些工作已经滑过这些裂缝。还要注意构建阶段是平稳穿过每个小组成员的，而产品化阶段的工作量班次在预期之内。通过运行像这样的图表，项目经理就能够更有效地管理他们的项目，确保所有的工作都分配并且每个都是激活的，从而防止大量的小组成员有太多工作的压力。 参考资料学习
|
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
