阅读 RUP 项目经理如何利用彩色编码在软件开发项目过程中帮助她的团队保持工件、角色以及职责的井然有序。

 彩色编码是一种用于各种行业中的常规技术，它提供对过程的洞察。着色为辨别、组织和管理关键的过程元素提供了可视化的提示。可视化令人们更好地理解过程目标，并且简化了提高生产力、降低缺陷率，并提高客户满意度的过程改进计划。

本文着重于我已经应用于实现软件开发行业中的这些改进的彩色编码技术。

着色的动机

彩色编码的核心理由是产品及过程的可追溯性。产品可追溯性确保产品满足客户的需求。如软件工程学会（Software Engineering Institute，SEI）的 能力成熟度模型集成(Capability Maturity Model Integration（CMMI）)所定义的那样，过程可追溯性确保开发过程满足组织的过程目标。我深信我创建并交付客户和公司所期望的每件事情。我需要数据来支持我们在项目中已经做了什么，和我们如何做的，以及我们仍需要做什么，和我们应该如何去做。着色可以为我的团队成员、管理层、外部的审计员和评估者，及最重要的客户更快速地检索关键的项目数据。

图 1 展示了上色的项目工件的实例。

图 1：显示上色的项目工件的工作区

过程可追溯性

我第一次使用着色是为了过程可追溯性。我是裁剪 IBM® Rational® 统一过程（RUP®）的过程工程师，并且需要组织许多适用于我的项目的工件、任务、清单，以及指导方针。我决定我的 RUP 2001 广告是将我的开发过程系统化的完美的调色板（参见图 2）。十分明显地绘制出九个 RUP Workflow 的阴影，各自的颜色选择都有逻辑意义。将什么颜色方案对我有意义进行文档化或描述不是本文的目的。对我的团队用言语解释 RUP 颜色选择已经证明十分有效地简化了 RUP 任务，“Launch the Development Case”。

图 2：在遗留的 2001 的颜色上添加的印刷的当前的 RUP 广告

我的过程可追溯性工作从装满了九个表示单独的 RUP 工作流的文件夹栅格开始（参见图 3）。这是我的过程栅格，我现在准备执行 RUP 任务，“Tailor the Development Process for the Project”。在我决定如何执行每个规程、裁剪其工件和任务、选择生命周期模型、描述示例迭代、确定项目涉众、将角色映射到工作职位上，以及为开发案例编写文档时，我记了注释 —— 许多注释。这些注释反映了所制定的决策的理由、可能影响决策的公司政策和过程、对 CMMI 关键过程域（KPA）元素的可追溯性，以及决策过程中的关键团队成员。我打印出我的注释，然后在所选的任务上花红线，并为我将裁减的步骤提供理由。我还打印出工件的副本、它们的清单和模板，以及任务的指导方针。然后所有这些数据被编档入栅格中各自彩色编码的 RUP 工作流文件夹中。

图 3：装有 RUP 工作流有色的文件夹的过程和项目栅格

编档技术可以通过使用标记（荧光记号、自粘的标记和注释，和纸夹子）以及编号方案对彩色编码添加另一个维度（参见图 4）。这在之后从栅格中去掉项时是有用的，因为可以更快地对它们进行再编档。在我执行 RUP 任务，“Support Development”时，过程可追溯性继续重复地向前。

图 4：包含 RUP 工作流和项目标识符的项目栅格目录

产品可追溯性

我用产品可追溯性来适合我项目工程师的角色 —— 几乎全部的 RUP 角色类别“Manager”，加上“Requirements Specifier”—— 来执行 RUP 任务。我的产品着色包括作为过程工程师而建立的现有的颜色方案。此外，我需要一个用于被开发系统的颜色方案（参见图 5）。我们所交付的系统包括硬件和软件元素，如果这些元素以及任意的子系统组件有独立的需求规范，那么我就将截然不同的且合乎逻辑的颜色分配给这些元素，以及任意子系统组件。

图 5：用分配给项目的在开发中的组件的颜色建模的用例实例

图 6 表示过程的颜色方案碰到过程的颜色方案的交叉点。对于粘着注释为组件分配它们各自的颜色，标记用于指示特殊工件表示的 RUP 工作流。

图 6：由分配的有色的附着注释所指示的项目系统组件

我的产品可追溯性工作也从装满了表示可应用的 RUP 工作流的悬挂的文件夹的栅格开始。这是我的项目栅格，根据过程裁剪实践来创建着色的 RUP 工作流文件夹。举例来说，业务建模不应用于我的大部分项目，因此它们的栅格将失去悬挂的文件夹。在我执行和分配 RUP 任务及工件时（参见图 7），我记下反应在执行的过程的注释，并且记录所做的决策，以及决策过程中的重要团队成员。这些被编档在项目栅格的各自的 RUP 工作流中，用于过程改进计划或项目追溯。

图 7：由系统组件所着色的项目团队成员的工件分配

对于 RUP 任务“管理依赖性”，我按照所分配的颜色对系统和子系统需求规范、设计元素，及测试可追溯性数据进行标记，并且在项目栅格中各自的 RUP 工作流文件夹中进行编档。项目栅格中不包含已经在配置管理（配置管理，CM）中维护的信息，并控制系统。它被设计为包含关于 CM 控制之下的条目的信息，包括追踪矩阵、质量控制记录，和支持客户审计的信息。这些追踪矩阵的完成推动开发团队审查需求、设计和测试信息 —— 因而令他们自己减少缺陷。彩色编码更简单且更快地为用例建模提供输入，并设计工场和需求、设计，及测试审查，从而确保我们涵盖了所有客户和过程的需求。

结束语

当我的团队成员要求过程指南（做什么、如何做，以及质量检查单），管理者需要项目工件的当前状态（包括什么时候审查它、谁审查它，以及遵照什么质量标准），CMMI 评估者需要满足 KPA 的客观证据，或者我们的客户希望看到这些时，用许多基本的办公用品（参见图 8）为过程着色的工作就有回报了。我已经能够快速地提供该数据，或者至少已经能够有信心地解释，为什么在导航追踪路径及到达合法的停顿之后一些东西不存在了。我没有抛开我的计算机搜索或者用不系统的信息检索方法纷乱地查看许多文件。

图 8：用于确认及组织过程和项目数据的过多的材料。

参考资料

• 您可以参阅本文在 develperWorks 全球网站上的 英文原文。
• 您可以参阅 Rational Edge 电子月刊中文版 的其他文章。

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