IBM Rational Doors

Doors概述

IBM Rational Doors是需求管理工具。Rational Doors集中的管理需求，并提供多种访问方式，方便开发团队的各种角色能够及时的、全面的了解需求。用户可以在Rational Doors的视图中(View)对需求的属性进行设置，并定制各种查询，排序，高效的理解需求的状态。用户同时可以建立需求追踪矩阵，了解需求改变的影响范围。

Rational Doors与Microsoft Word紧密集成，通过Rational Doors与Word的同步功能，自动的将Word文档中的需求抽取到Rational Doors的视图当(View)中。Rational Doors提供WEB界面，使得团队可以非常好方便的进行交流，提高工作效率；Rational Doors与Rational ClearQuest紧密集成，项目经理、架构师、系统分析师等可以及时了解需求变更的影响；Rational Doors与Rose紧密集成，将需求与UML模型进行关联，更准确地表达需求的定义。

3.1.2产品特性

n 需求条目文档化的展现和统一的需求存储中心

在任何高效的需求管理过程中，需求捕获和记录是需求管理成功的关键一步。这可以确保对不断发展的需求进行准确地交流与管理。文档是记录需求、提供上下文或补充需求信息的最佳格式，IBM Rational的需求管理解决方案利用了广泛使用并为人熟知的Microsoft Word工具来简化需求信息的捕获。

n 基于数据库的需求信息统一管理

虽然文档有助于需求信息的捕获，但它并不是对信息进行优先级划分和管理的最优环境，为保证这些活动的执行，IBM Rational的需求管理方案还提供了统一的需求存储中心，通过将需求文档链接到统一的存储中心，IBM Rational的需求管理解决方案平滑地将文档与数据库的优点统一起来。

n 多手段高效的需求信息管理能力

通过指定如优先级、难度和状态等属性，可以帮助团队某种程度上实现紧靠使用文档所不可能完成的需求信息管理工作，IBM Rational需求管理解决方案提供了现成的标准属性和属性值，同时可以帮组团队轻松自定义，以支持团队的需求处理过程和术语。

结合数据库和Word的特点，IBM Rational需求管理方案可以提供组织、排序、过滤和跟踪需求信息的方法，从而提高团队成员间的交流，团队的协作能力和降低项目风险

n 需求变更管理

在开发过程中，需求变更是不可避免的，因为它表明了项目的渐进明细的特点，但是如果缺乏管理的需求变更则会使项目慢慢偏离需求所要满足的系统特征和需要。IBM Rational需求管理解决方案可以通过对需求分类，创建不同类型的需求链接关系，可以轻松地确定并分析需求变更所带来的影响。通过跟踪矩阵，跟踪树等功能，当某种需求发生变化时，可以很容易地看出它对其他需求的影响，可以查明需求变更对整个项目的影响并评估影响范围，以便进行核实和确认。利用这种分析变化影响的能力，管理团队可以做出快速明智的决策，进行范围管理后资源重分配。

每个需求项的版本记录能力，使得需求管理团队可以方便查阅需求变更历史过程。随着需求的发展，所做的每一个修改都会被捕获跟踪并全部存档于Rational需求管理平台中。需求审核跟踪将把谁，什么，为什么和什么时候修改的需求进行存档，帮助需求管理团队分析它对整个项目的影响。

n 有效的团队沟通

IBM Rational需求管理解决方案可以同IBM Rational配置管理解决方案、质量管理解决方案等其他方案有效集成，提高团队跨工具和项目集成需求，优化团队围绕需求的沟通和协作。

同配置管理解决方案的集成，提高需求变更过程的管理。通过和IBM Rational配置管理解决方案ClearCase和ClearQuest的集成，可以保证团队中开发人员，项目经理，测试人员等不同成员围绕着需求变更进行有效的沟通。例如：随着项目的渐进明细，不可避免地会出现需求变更的请求，同配置管理解决方案的集成，通过将变更请求与那些可满足这些请求的需求相关联，简化将重要相关者得反馈送入项目的下一阶段的过程，因此当对下一阶段需求进行优先级排列式可以从容地考虑用户的需求同质量管理解决方案的集成，提高测试人员对需求的访问，从而确保测试人员确定他们正在检验的是正确的。

IBM Rational需求管理解决方案可以同质量管理解决方案平滑集成，这样可确保将需求用作创建测试用例时的直接输入，测试人员和QA工程师就可自信地验证系统。并且随着需求更改的发生，测试人员可以真实地察看需求更改会对哪个测试用例产生影响.

3.2.1变更管理工具

3.2.1.1 ClearQuest概述

IBM® Rational® ClearQuest是一个强大而高度灵活的缺陷和变更跟踪系统，能在整个开发周期内捕获、跟踪并管理各种类型的变更请求，帮助您以更高的效率交付出更高质量的软件。无论您使用的平台是Windows、Unix或是Web，可完全自主定制的界面和工作流程引擎都能适应任何开发流程。由于ClearQuest支持业内标准数据库，所以它可任意扩展，以支持任何规模的项目。

建立单一自动化、针对各种变更请求管理及缺陷追踪系统，可供所有项目参与者使用。如此可确保团队成员间的信息流通无碍，每位成员都能掌握缺陷的状态以及功能增强请求。这些信息对协商软件项目的变更流程极为重要，但目前对项目成员而言，并不容易将这些信息整合。在工具中追踪和储存这些信息将有助于设计人员、开发人员、QA 人员了解系统的变化，并可让项目经理将项目状态报告的建立流程自动化。

通过对开发整个生命周期中发生的各种类型变更请求的跟踪及管理，保证各种规模的开发团队按照预定计划按期交出高质量的软件产品。适用于在任何平台上，任何类型的项目中，捕获各种类型的变更。ClearQuest 使用行业标准数据库（Microsoft Access、 SQL Server 、DB2、Oracle）；并拥有可完全定制的接口和工作流程机制，能适用于任何开发过程。此外，通过提供各种各样的流程模板，对于一般的开发环境和流程，可以做到“拿来就用”或“稍做修整，即可使用”的方便而灵活的部署。

ClearQuest与IBM Rational的其它解决方案（如配置管理工具、自动测试管理工具、需求管理工具）的整合，使团队开发的各个角色在开发的各个阶段都可以随时递交变更请求，成为支持软件开发整个生命周期的变更管理的有效工具。

 

3.2.1.2产品特性

n 有效的记录、管理和追踪变更请求

通过多种易于使用的客户端（Windows，UNIX，Web，Email），在任何地点、以任何方式都可以捕获在整个开发生命周期中出现的各种类型的变更请求，包括测试阶段发现的缺陷、需求分析阶段的需求扩展请求等等。所有的变更请求在ClearQuest中被集中存储在统一的数据库之中，以便进行各种形式的查询，同时也便于集中管理。另外，ClearQuest给变更请求还附加了状态信息，以便于追踪变更请求的发展状态。

n 促进团队的沟通和协作

提供一套完备的电子流程管理系统。它可以利用企业现有的邮件服务系统实现自动电子邮件通知功能。当系统内提交了新的变更请求或已有变更请求的状态发生变化时，ClearQuest会自动通过电子邮件通知相关的人员，从而大大促进团队的沟通和协作。

n 随时随地了解项目状况

支持通过WEB的方式对系统进行访问，在浏览器中可以查询变更请求的状态、浏览变更请求的信息、生成多种统计分析图表和项目状态报告。所以，项目经理无论是在公司还是在外地出差都可以及时准确的了解项目的状况。

n 灵活、客观的项目统计指标

查询、图表（年龄、趋势、分布图表）、报告（与SoDA整合）功能，使得项目管理人员能够方便、准确地得到项目统计资料，如：

“变更请求是否在团队成员中被合理分配?”

“还有多少优先级为1的缺陷未得到处理?”

“平均修复一个错误需要多长时间?”，

“实现一个新增需求需要花多少时间?” 

“在两个月内变更请求数量的变化曲线”

依赖各种项目统计资料，项目管理人员就可以进行更加科学、量化的管理、规划、调配、监控，保证项目如期的进行。

n 系统可定制能力

在ClearQuest系统中所涉及的窗体信息域、状态变迁过程、分析图表和状态报告等都是可以根据企业的实际需要进行定制的，并且可以随项目的发展不断进行调整。所以，ClearQuest可以适用于任何类型以及任何规模的项目。对于一个立足长远发展的企业而言，ClearQuest是一笔可以长期保值的投入。

3.2.2配置管理工具

3.2.2.1 ClearCase概述

导入共同的配置管理 (CM) 流程以提升软件开发效率。使用 CM 流程和工具可控制项目文件和程序代码的版本，并随着项目的发展，支持在共享原始码所衍生的不同程序代码基础上进行平行开发。配置管理流程必须定义产品架构：系统、子系统和组件。这些将使配置得以控制产生对象的目录结构，并使 CM不但可控制原始程序代码，还可控制所有项目产生对象。提供跨团队和分散地点的共同配置管理系统，以提供更易于整合的机制。

3.2.2.2产品特性

n 版本控制

版本控制是所有配置管理系统的核心功能。配置管理系统的其它功能大都建立在版本控制功能之上。版本控制的对象是软件开发过程中涉及的所有文件系统对象，包括文件、目录和链接。可产生版本的文件包括源程序代码、可执行文件、位图文件、需求文件、设计说明、测试计划、和一些ASCII和非ASCII文件等等。目录的版本记录了目录的变化历史，包括新文件的建立、新的子目录的创建、已有文件或子目录的重新命名、已有文件或子目录的删除等等。

版本控制的目的在于对软件开发进程中文件或目录的发展过程提供有效的追踪手段，保证在需要时可回到旧的版本，避免文件的丢失、修改的丢失和相互覆盖，通过对版本库的访问控制避免未经授权的访问和修改，达到有效保护企业软件资产和知识产权的目的。另外版本控制是实现团队平行开发、提高开发效率的基础。

文件或目录的版本演化的历史可以形象地表示为图形化的版本树（Version Tree)。版本树由版本依次连接形成，版本树的每个节点代表一个版本，根节点是初始版本，叶节点代表最新的版本。最简单的版本树只有一个分支，也就是版本树的主干；复杂的版本树（如平行开发下的版本树）除了主干外，还可以包含很多的分支，分支可以进一步包含子分支。

一棵版本树无论多么复杂，都只能表示单个文件或目录的演化历史，但典型的软件系统往往包含多个文件和目录，每个文件和目录都有自己的版本树，多个文件的版本需要相互匹配才可以协同工作，共同构成软件系统的一个版本或发布。因此为管理软件系统的发布，单有版本树是不够的，还需要引入基线（Baseline）的概念。基线由每个文件的某一个版本构成，是开发和进一步演化的基础。如果将全部版本树看作一个森林，基线则是该森林的一个横截面（该横截面往往不是水平的，而是上下起伏的折面）。

有了版本控制和历史版本，版本之间的比较就变得非常有意义，配置管理工具应能有效支持版本的图形化的比较。

n 工作空间管理

仅仅有版本控制功能还是不够的，在某一时刻，开发人员的开发工作往往只工作在文件的某一选定的版本上，因此配置管理系统需要提供一种便捷的访问正确文件的正确版本的机制，这正是配置管理系统的工作空间管理功能。所谓工作空间，就是为了完成特定的开发任务（如开发新功能、进行软件测试、或修复BUG，等等），从版本库中选择一组正确的文件/目录的正确版本拷贝到开发人员的开发环境。举例说明：为修复一个旧版本，如REL1中的BUG，开发人员首先需要在自己的开发环境中完全重现REL1所对应的源文件和目录结构，也就是说，需要建立一个对应于REL1的工作空间。

存在两类工作空间，一类是开发人员的私有空间，在私有空间中，开发人员可以相对独立地编写和测试自己的程序代码，而不受团队中其它开发人员工作的影响，即使其它人也在修改同样的文件；另一类工作空间是团队共享的整合空间，该空间用于整合所有开发人员的开发成果。

工作空间管理包括工作空间的创建、维护与更新、删除等，工作空间应具备以下特点：

稳定性：工作空间的稳定性指的是私有空间的相对独立性，在私有空间中，开发人员可以相对独立地编写和测试自己的程序代码，而不受团队中其它开发人员工作的影响。

一致性：工作空间的一致性指的是当开发人员对自己的私有空间进行更新时，得到的应该是一个可编译的、经过一定测试的一致的版本集。

透明性：工作空间的透明性指的是工作空间与开发人员本地开发环境的无缝整合，使配置管理系统对开发环境的负面影响降到最小。

缺少有效的工作空间管理会造成由于文件版本不匹配而出错和降低开发效率，更长的整合时间等问题。

n 并行开发支持

如图1所示，在传统的串行开发模式下，同一软件的多个发布（Release）是顺序地被开发出来的，也就是说Release 1全部开发结束后才开始Release 2的开发；同样，等Release 2全部开发结束后Release 3的开发工作才会启动。但这种串行开发模式在当今的市场环境下越来越行不通，因为所有的软件产品都面临越来越大的迅速上市的压力，唯一有效的解决方案就是引入并行开发机制。在并行开发模式下，同一软件的多个版本会同时进行开发，如Release 1开发尚未完成，往往就会同时启动Release 2的开发，甚至会同时启动Release 3的开发，从而有效缩短软件的上市周期。为实现有效的并行开发模式，需要一种机制将Release 1中后期开发的功能合并到Release 2中，这正是配置管理工具需要完成的。

               

                             图1：串行开发与平行开发的比较

为实现并行开发，配置管理系统需要提供灵活的分支机制和工作空间管理。创建分支的过程实际上就是一个建立副本的过程，针对每个发布分别建立相应的分支，分支之间具备相对的独立性，这样不同的发布就可以在各自的分支上并行进行开发，在适当的时候，分支之间可以进行合并，从而实现将Release 1中后期开发的功能合并到Release 2中。

对同一软件的多个发布的并行开发其实只是诸多并行开发模式和分支策略之一，其它常见的并行开发模式有：

并行进行同一产品的维护和开发：

并行开发同一产品的多个定制版本：

并行开发同一产品的多个特性：

团队协作并行开发一组相同的文件/目录：

n 过程控制

不同的开发组织往往具备不同的组织结构、不同的开发环境、不同的开发策略，因此，配置管理系统应该能够支持灵活的配置管理策略和配置管理流程，并实现过程自动化以提高配置管理效率，这就是过程控制需要实现的功能。

大家都知道，在商用关系型数据库中有一种触发器（Trigger），通过触发器机制，可以定义在记录被插入/删除之前或之后自动执行一个预定义的脚本来实现特定的逻辑功能；配置管理系统应能够提供类似的触发器机制。通过可定制的触发器，可以定义在执行特定的配置管理操作（如检出、检入）之前或之后自动执行特定的任务（可以是批处理、可执行档、或其它的配置管理操作），从而自动化实现预定义的配置管理策略。

过程控制还可以通过对配置项加锁/解锁来实现，如在版本库备份阶段对版本库进行加锁以禁止在备份过程中的版本库的修改。

通过过程控制还可以设置额外的安全访问机制以加强配置管理系统的安全策略。

IBM Rational更是提供了一个基于最佳实现经验的流程——统一变更管理UCM（Unified Change Mangement），UCM的经验来自上百个客户的数千个项目，用户可以在短时间内（不需要额外的定制，或仅仅通过简单的定制）共享到其它客户在软件建构管理上的经验，一方面可以充分发挥软件建构管理带来的好处，另外节省了大量时间及成本。

n 构建(Build)和发布管理

简单而言，构建和发布管理的目的有三个：确保软件构建是可重现的、高效的、和可维护的。在小型的软件开发项目中达到以上三个目标并不困难，但随着开发团队、软件规模、软件复杂性的增长，以上的三个目标已经成为一种挑战。

典型的构建和发布管理包括以下几个步骤：

步骤一：确定参与构建的全部资源（如原始码、文件档、…等）的正确版本；

步骤二：基于步骤一中选定的正确版本创建一个干净的仅仅用于构建目的专用工作空间，这里“干净”意味着该工作空间中没有多余的文件/目录，不存在旧的中间档，所有档应该是只读的，不允许进行检出和修改；

步骤三：执行构建过程，并对构建过程进行审计。审计信息包括但不限于：谁执行的构建？什么时候执行的构建？构建生成的可执行档或库包含哪些内容？执行构建的机器是什么？机器上运行的操作系统版本是什么？执行构建使用的是什么编译器？使用了编译器的哪些选项？等等。构建审计是确保构建重现性和可维护性的有力保证。

步骤四：对构建和审计过程中产生的导出档（Derived objects）进行版本控制。这一点很重要，正是这些导出文件构成了软件发布的重要组成部分。

步骤五：为业已受控的导出文件建立基线。

步骤六：生成软件发布介质。

构建的高效依赖于对导出档在多次构建中的共享，通过避免反复生成同样的导出对象来大大缩短构建的时间。

n 异地开发支持

经济全球化趋势、越来越多的企业兼并以及软件规模和复杂性的不断增加等诸多因素使得地理上分布的多个软件开发团队进行协作开发的开发模式日益普遍。这些团队可能分布在同一个城市的不同的办公地点，也可能分布在一个国家的不同城市，甚至分布在全球不同国家的不同城市。配置管理系统应该能够有效支持以上地理上分布的团队之间的远程协作。

典型的异地开发模式具有以下特点：

Ø 支持跨多个地点的分布式开发：异地开发团队应该能共享开发成果，在甲地的开发工作可以在乙地进行集成；甲地可以在乙地的开发基础上进行。

Ø 复制和同步配置数据：无论网络带宽如何发展，相对本地网络及磁盘存取速度，远程网络的带宽总是相对有限的，因此如何高效、可靠地在异地之间复制和同步配置数据是异地开发和远程协作的关键。

Ø 提供配置数据的本地存取：出于效率上的考虑，开发人员的日常开发工作应该是基于本地存取的方式，而并应该依赖与远程网络连接。

需要说明的是，异地开发支持不等同于各地通过远程网络连接到单一的版本库的开发模式，由于广域网带宽的限制，单一的 版本库模式被证明是低效的和不实用的；典型的异地开发模式在每个地点都有版本库的副本，日常开发针对本地版本库进行，版本库之间具有复制和同步机制。

n 统一变更管理 

ClearQuest可以和配置管理工具ClearCase整合，从而将变更管理和配置管理对象有机的联系到一起，形成统一变更管理。ClearQuest与ClearCase整合是通过将ClearCase的版本对象库（VOB）与ClearQuest的数据库相关联来实现的，整合后开发人员在修改程序代码（Check Out）时会自动弹出ClearQuest的变更请求窗口，并强制开发人员将此次修改与特定的变更请求相关联。这样一来，开发人员在程序代码提交时可以清楚的知道哪些修改过的程序代码是对应哪些任务的，整合人员可以准确的了解到某次建立到底整合进来哪些变更请求。项目经理可以轻松的定位变更请求和哪些改动相关。