【IT168 技术文档】第一部分链接：http://tech.it168.com/m/2007-12-30/200712302348235.shtml

3.2.2 IBM Rational配置及统一变更管理解决方案

    基于GJB5000-2003和GJB2786-96质量保证体系的军工单位的管理类、开发类和支持类的所有过程都强调或遵守对工作产品和变更“进行管理和控制”，正如图表3-6所示。这意味着在给约定时间（过去或现在）使用的工作产品的版本是已知的（即版本控制），而且以受控的方式引进更改（即更改控制）。但是正如我们面临的问题那样，如果没有对过程支撑的相对应的工具平台，过程实施每一个环节将很难落到实处。

    IBM Rational 配置及统一变更管理平台正好作为一种特定的工程技术解决方案为军工单位的软件配置管理（以下简称SCM）过程提供了一种具体可操作的实践手段。

    IBM建议军工单位的软件开发团队可以在基于现有SCM过程改进的同时，导入IBM Rational 配置及统一变更管理平台。我们给您这样的建议是基于以下的充分理由。

图表 3 6 IBM Rational配置及统一变更管理解决方案。

3.2.2.1 方案主要功能特性

3.2.2.1.1 确保军工单位软件资产的安全性

    IBM Rational配置及统一变更管理解决方案的首要任务，就是要在安全的存储库中对工作产品进行正确的标识和存储，从而进行有效的版本控制。需要标识和存储的工作产品包括：项目计划、需求文档、设计模型，源代码、库文件、可执行文件、Web内容、测试计划、测试用例、测试脚本等等。对工作产品进行正确标识的目的就是确保在需要时能够简单、快速地找到它们的正确版本。 

    IBM Rational配置及统一变更管理解决方案实现以下功能:
 对软件开发过程中的全部工作产品进行版本化管理，包括代码、各种文档、目录模型、测试脚本、图形和各种二进制文件等；

 在安全的存储库中进行工作产品的标识和存储，安全的存储结构和灵活的权限设定，杜绝了任何未经授权的变更，保证了军工单位软件资产的安全，有效保护军工单位的核心资产。

 控制并审计对工作产品的变更：在标识和存储工作产品的基础上，配置及统一变更管理解决方案还对工作产品的变更提供有效的控制手段和审计能力。控制对工作产品的变更指的是能够设定谁能够对哪些工作产品进行修改；对工作产品的变更进行审计指的是能够记录与工作产品修改相关的所有操作历史信息记录：包括谁进行的修改，修改了什么，什么时候进行的修改，为什么要进行修改？

图表 3 7 IBM Rational配置及统一变更管理解决方案确保军工单位资产安全 

    3.2.2.1.2 确保软件发布版本的完整性 

    IBM Rational配置及统一变更管理解决方案中的ClearCase使用标签来标记某一特定的基线，如图所示，标签可以是任意的字符串：

图表 3 8 IBM Rational配置及统一变更管理解决方案确保软件发布版本的完整性 

    在项目里程碑创建正确的基线和完善的基线管理，可以确保设计与需求的一致性、代码与设计的一致性、使用正确的代码进行发布等。适时创建基线有以下好处： 
   
 可重现性：有能力准确回到任何一个先前的软件版本。
 可追踪性：保持项目需求、项目计划、测试用例等与源代码之间的一致性和可追溯性。
 配置状态报告：有了适时创建的基线，就可以查询、报告、比较基线的内容。 

    3.2.2.1.3 将工作产品组织为版本化的构件 

    所谓版本化的构件就是一组相关的文件和目录，这些文件和目录作为一个单一的单元进行版本控制、基线管理、编译/构建，共享和重用。将工作产品组织为版本化的构件有以下好处：
 降低复杂性：构件通过提高抽象层次来有效降低复杂性，使得问题更加易于管理。
 标识构件的质量水平比标识单个文件的质量水平更有意义；
 有利于共享和重用；

图表 3 9 版本化的构件 

    3.2.2.1.4 建立统一变更管理平台，作为整个软件开发团队的工作平台 

    变更请求有多种形式并且来自不同的地方，如来自内部及外部的错误报告；来自业务及工程部门的功能增强请求；需求、设计、及文档变更请求，等等。我们不仅需要一个合理的过程来对变更请求进行记录和跟踪，可能的话，还应该对实现变更请求而造成的相关工作产品的变化结果进行跟踪。如图3－10所示的IBM Rational的统一变更管理的提供了以活动为中心的软件开发过程的组织和协作，自动为每个开发活动维护一个一致的变更集，基于活动可以对其变更集进行统一的检出、检入、集成、编译和建立，从而有效组织了统一变更管理的三个基本要素：人、活动、工作产品，准确标识当前发布包含哪些新功能、当前发布对已有功能进行了哪些增强、当前发布修复了哪些缺陷等。

图表 3 10 IBM Rational的统一变更管理平台 

    3.2.2.1.5 维护稳定和一致的工作空间 

    维护稳定和一致的工作空间是实现并行开发、提高开发效率的必要前提。存在两类工作空间，一类是开发人员的私有空间，在私有空间中，开发人员可以相对独立地编写和测试自己的代码，而不受团队中其他开发人员工作的影响，即使其他人也在修改同样的文件；另一类工作空间是团队共享的集成空间，该空间用于集成所有开发人员的开发成果。
所谓工作空间的稳定性指的就是私有空间的相对独立性，在私有空间中，开发人员可以相对独立地编写和测试自己的代码，而不受团队中其他开发人员工作的影响。每个开发人员都有自己的私有工作空间，不同开发人员的私有工作空间是相互独立、彼此隔离的。所谓工作空间的一致性指的是当开发人员对自己的私有空间进行更新时，得到的应该是一个可编译的、经过一定测试的一致的版本集。 

    3.2.2.1.6 支持对构件的并行开发 

    传统的串行开发模式在同一时间只允许一个人对同样的文件进行修改，其他需要修改同样文件的人只能等到前面的人修改完成后再开始自己的修改，这样的好处是不会出现修改上的冲突，但在当今的市场环境下，这种串行开发模式显然是行不通的，因为它既不现实、也缺乏效率，取而代之的是并行开发模式。具备强大的分支和自动化合并的能力，以有效支持并行开发，提高开发效率。

图表 3 11 IBM Rational配置及统一变更管理解决方案提供的软件并行开发能力 

    3.2.2.1.7 确保软件构建的再现性 

    有时出于排错的需要，或需要重现相同的构建（Build），我们需要知道软件是如何被构建的，构建中包含哪些内容，这就要求配置管理系统提供构建审计功能。 

    构建审计功能应能自动记录以下内容：谁执行的构建？什么时候执行的构建？构建生成的可执行文件或库包含哪些内容？执行构建的机器是什么？机器上运行的操作系统版本是什么？执行构建使用的是什么编译器？使用了编译器的哪些选项？等等。有时候仅仅改变编译器的优化选项开关就可能引入新的错误，有了构建审计功能，就有可能进行不同构建的比较，从而有利于排错。缺乏软件构建的再现能力就很难进行软件系统的维护，对在客户现场运行的系统更难提供有效的技术支持。 

    3.2.2.1.8 有效监控项目质量和状态 

    IBM Rational配置及统一变更管理解决方案可以实时提供有关项目的以下信息： 
   
 资源分配：变更请求是否在团队中被平均分配?
 项目状态：还有多少优先级为1的缺陷未得到处理?
 趋势：平均修复一个错误需要多长时间?实现扩展请求需要花多少时间?
 测试进度：有多少缺陷处于验证状态? 
   
 从而，保证项目开发过程中各级领导、业务人员和项目管理者，及时、自动地了解项目管理状态，量化内部项目人员及供应商项目组成员工作量，工作进度，确保项目的质量和进度。

图表 3 12 IBM Rational配置及统一变更管理解决方案实现对项目进度和质量的监控
3.2.2.2 IBM Rational配置及统一变更管理平台工作过程设计

    工作过程如下图所示：

图表 3 13 配置管理过程 
   
3.2.2.2.1 搭建配置管理环境 

    搭建配置管理环境包括以下步骤： 
   
1) 建立基础操作系统及网络运行环境
2) 安装ClearCase和ClearQuest客户端软件。
3) 规划配置库结构，包括详细的组件划分及目录结构。
4) 规划用户组，包括项目管理组，开发组以及业务组等。在NIS服务器、Windows域控制器以及ClearQuest中建立相应用户及组。
5) 在配置管理服务器端建立一个为项目服务的项目管理库（PVOB），用于存放配置管理元数据。
6) 根据组件数目及逻辑关系等建立组件配置库（Component VOB）。
7) 按照规划的配置库结构准备初始导入文件。
8) 制订项目策略，确定项目中哪些组件是只读的，哪些是读写的。
9) 确定ClearCase并行开发模式。
10) 在ClearCase Explorer中通过New project创建项目（project），选择项目所用组件，确定组件访问方式（只读/读写），并选择并行开发模式。 
   
3.2.2.2.2 开发人员加入项目，创建开发人员工作视图 

    通过ClearCase Join Project Wizard来完成。Windows客户端用户均使用静态视图。 
   
3.2.2.2.3 开发人员在开发空间进行变更 

    通过checkout、checkin、undo checkedout、find checkedout等操作在ClearCase Explorer、Windows Explorer或命令行窗口中实现。 

    3.2.2.2.4 开发人员提交工作成果 

    通过deliver from stream to default来实现。该操作可以在ClearCase Project Explorer中完成，也可以在ClearCase Explorer中完成。 
   
3.2.2.2.5 集成人员集成上交结果，建立基线 

    通过ClearCase Project Explorer实现，具体操作为make baseline。另外当基线达到某种稳定程度后可以使用修改promotion level以及recommended baseline来进行基线提升以及推荐基线标识。 
   
3.2.2.2.6 开发/测试人员与项目基线的同步 

    通过rebase stream来实现实现。该操作可以在ClearCase Project Explorer中完成，也可以在ClearCase Explorer中完成。 
   
3.2.2.2.7 ClearCase和ClearQuest集成工作过程设计 

    ClearCase和ClearQuest集成过程设计如下图所示：

图表 3 14 配置管理过程总图
3.2.3 IBM Rational软件开发生命周期质量管理解决方案

3.2.3.1 方案主要功能特性

    军工单位在软件过程执行中一个强有力的软件质量管理工具是必不可少的。“软件质量管理平台”基于全面质量管理理念，符合GJB5000-2003和GJB2786-96质量保证体系的要求，将军工单位的软件过程融入日常项目开发，实现管理与技术的融合，能够有效提高管理效率，降低了理成本，保证产品质量，是一个能够全面、有效管理软件开发的协同工作平台。IBM将这一管理平台形象的比喻为“软件开发生命周期的集线器（Hub）”，其主要功能覆盖：
 需求获取管理
 缺陷跟踪管理
 变更管理
 测试管理
 软件质量保证（SQA）
 同行评审
 软件测量 

    该平台围绕军工单位软件开发的基本盈利单位——软件项目开发进行管理，确保软件
项目依据厂里规定的过程要求制定计划、调配资源、监督开发产品。通过对开发过程的量化度量与控制，尽早发现和解决项目中存在的问题，规避项目风险。 
   
1. IBM® Rational® ClearQuest功能简介 
   
    IBM® Rational® ClearQuest是一个强大而高度灵活的需求获取、缺陷跟踪、变更管理和SQA审计（audit）系统，同时又是新一代软件测试管理工具，实现了测试需求、测试用例以及缺陷的集中管理，充分实现了需求团队、开发团队以及测试团队之间信息的共享和团队协作。 

    军工单位可利用ClearQues完全自主定制的界面和工作过程引擎在整个开发生命周期内定制自己的开发和管理活动的处理过程，包括过程处理状态、过程涉及的数据以及过程涉及的表单布局及设计等。
同时，军工单位可以通过项目管理、历史记录、附件、审计跟踪、电子签名、Email通知等几十个预置模型包快速定义用户自己的管理过程。 

    ClearQuest除了能对需求、测试、缺陷和审计进行有效的状态跟踪外，还对信息提供了强大的数据查询、统计分析以及报表功能，通过这样的数据测量功能确保项目团队能快速、准确把握软件产品质量、测试进度状况以及团队工作负荷等方面的信息。 

    ClearQuest在存储上基于大型关系数据库，如DB2、Oracle和SQL Server等，中间件基于IBM WebSphere的应用服务器，并提供全中文的Eclipse客户端和浏览器客户端，完全满足企业级部署的需求。
利用ClearCase和ClearQuest的集成活动会自动传入开发人员工作环境。开发人员以分配给自己的活动为依据进行代码修改，所做修改会自动关联到相应活动。


图表 3 15 ClearQuest功能
3.2.3.2 规范统一的需求获取平台

    有效的项目需求管理的内容包括对需求来源以及需求开发过程的理解，对需求质量的共识，以及需求管理策略。需求信息收集方案主要是针对军工单位的所有已经实施、正在开发和即将开发的产品或项目的以下需求信息进行收集、过滤、分拣、评估、规划、评价： 
   
 前版本遗留问题；
 用户需求；
 版本运行问题；
 功能增强性建议，可以来自用户方、开发方或分包方；
 上级任务。 
   
    根据军工单位的《用户要求过程》中的过程，ClearQuest帮助军工单位建立项目团队的需求收集平台，统一需求收集的渠道和信息提交的格式，并遵循必要的需求评估过程，对收集的原始需求进行遴选、分派，同时又能完整保留所有原始需求。ClearQuest具有根据客户需求进行灵活定制的能力，有简单易用的Web界面，使得由客户和业务人员直接提交原始需求成为可能。如图表4－16所示，这样的需求获取平台满足并具体化了这个过程的如下目标和关键活动： 
   
1. 目标 

    用户要求过程活动的目标是针对系统或软件产品提出详细的要求，拟制方案和合同，确定开发单位和验收准则。
2. 输入 

    ——过去类似项目数据库
3. 活动 
   
 描述对系统或软件产品的要求。
 定义和分析系统需求。系统需求除了应包括设计、测试、标准和过程的描述，还应包括商务、组织结构、用户、安全保密等内容。
 如果用户指定开发方分析系统需求，用户应验收经过分析的需求。
 用户自己或指定开发方来完成软件需求定义与分析。

图表 3 16 需求获取平台
3.2.3.3 测试管理自动化和缺陷跟踪平台

    测试管理是指对系统测试活动的管理，其主要目的是测准（有效选择运行测试用例，发现系统的缺陷）和测全（保证所有需求对被测试过）。 

    不同阶段的测试的依据是以其上游输出的工作产品为依据，测试人员只有准确把握需求信息，才能进行有效的测试。同时，测试人员的职责不仅仅是发现缺陷，还有帮助开发人员重现并解决缺陷的义务，应该为开发人员提供缺陷的相关信息，以帮助开发人员快速定位并解决问题。因此，测试管理不仅仅以测试用例为核心，还应考虑对需求和缺陷信息的管理，并建立需求、测试用例、测试脚本以及缺陷的关联。 

    测试管理自动化的主要目的是通过ClearQuest自动能获得软件质量以及测试过程的相关信息，从而及时有效地指导软件测试。 

    通过测试管理自动化，测试人员能把更多精力关注在如何设计有效的测试用例，如何有效选择执行测试用例，从而保证系统质量。 

    软件开发过程中开发与测试由独立进行，有利于客观的找出软件中存在的问题。但是这种独立也会产生问题，每个独立单位都倾向于从自身任务出发，而不是从以最短的时间、最低的缺陷水平把产品提供给顾客的整体目标出发。常常像有一面无形的墙把开发和测试群体分开，开发部门把它的产品通过看不见的抛给测试部分，并等待测试部门在测时发现问题；然后测试部门又把代码通过墙抛回给开发部门，还附带一系列要修改的问题。这种“通过墙扔过去”的态度最终后果是开发部门花更多的时间去改正错误，而测试部分花更多的时间试图逮住错误，在这种情况下，通常送测都要反复多次，因此测试的时间得不到控制。正如下图表4－17所示，由此带来的产品质量总是很低下。

图表 3 17 缺陷与产品质量 

    所以，军工单位借助ClearQuest的以下优势建立测试管理自动化和缺陷跟踪平台可以快速弥补这方面的劣势： 
   
 协调测试过程中的测试活动、测试资产(Asset)和测试人员
 追踪测试资产之间的依赖关系
 迭代地进行测试计划、测试执行和测试评估
 知道当前被测试系统的质量
 定义、测量和跟踪系统的质量目标
 自动化测试管理
 跟踪测试计划和测试用例
 跟踪需求和缺陷
 执行测试
 测量测试进度 
   
    测试管理自动化和缺陷跟踪带来的好处是： 
   
 提供了集中查看整个项目状态的实时视图
 记录了开发、测试和项目工件之间的可追踪、可审计的关系，如图3－18所示
 管理项目计划、测试结果、质量度量和缺陷
 集成了版本控制的集中存储库
 提供了广泛的度量报告
 需求 <-> 测试用例的追踪
 缺陷 <-> 测试用例的追踪
 测试日志 <-> 需求的关联
 缺陷 <-> 测试日志的关联
 建立需求到测试、缺陷的追踪关系，实现软件开发的闭环

图表 3 18 缺陷跟踪平台 

    以上平台满足并具体化了军工单位的软件测试过程和软件问题处理过程的如下目标和关键活动： 
   
1. 软件测试过程
a) 目标 

    软件测试过程活动的目标是由测试用例生成测试程序，通过执行测试程序发现软件问题。软件测试过程使用的软件测试方法包括单元测试、集成测试、系统测试、验收测试、回归测试等等。软件测试过程包括测试程序编写和调试、测试程序和测试结果评审、结构覆盖分析、测试报告生成等活动。
不同的项目，可根据项目的规模、可提供的资源、经费、软件等级选择部分或全部测试步骤。可以针对测试对象的不同特点采用不同的技术，发现不同特征的错误，使软件在多层次测试中不断提高质量。 
   
b) 输入 
   
——软件需求规格说明
——接口需求规格说明
——软件设计文档
——接口设计文档
——软件测试说明
——过去类似项目的测试程序 

    c) 活动 
   
 设计和调试测试程序。有了测试用例后，就可以按照软件开发计划和/或软件测试计划中指定的测试程序设计方法设计测试程序。测试程序要在测试计划规定的测试环境下进行调试。 
   
 评审测试程序和测试结果。测试程序调试结束后，保存运行结果。按照软件同行评审的过程和方法，对照检查单对完成的测试程序和测试结果进行评审。测试程序和测试结果检查单的格式见附录G 
   
 覆盖分析。覆盖分析分两步进行，即基于需求的覆盖分析和结构覆盖分析。第一步分析与软件需求有关的测试用例，以证实所选的测试用例满足指定的准则。第二步证实基于需求的测试程序测试了代码结构。覆盖分析按照覆盖分析检查单进行，格式见附录G。 
   
 生成软件测试报告。整个测试过程的最后步骤是生成软件测试报告。软件测试报告是对整个测试过程的总结，包括下列内容：使用的资源环境、测试方法、测试用例、测试结果、所发现的错误、对被测软件的分析。 
   
 测试过程中发现问题的处理。在评审、分析、测试用例编写、测试程序编写和调试执行等一系列测试步骤中，若发现被测软件有问题，按照规定的格式填写被测软件问题报告单。若为独立的第三方测试。该报告要按照事先规定的要求，提交给专门的问题报告处理组织。若为开发测试，则由开发者按照项目规定的问题报告处理步骤处理，如先由专家组确定是否是问题，影响如何，如何更改，由谁完成更改，计划完成更改时间等，然后由程序设计者实施更改，直至最终解决问题。 

    2. 软件问题处理过程 
   
a) 目标 

    软件问题处理过程活动的目标是记录、分析、更改、跟踪、解决软件中发现的问题。 
   
b) 输入 
   
——软件问题报告单 
   
c) 活动 
   
 由设计师系统确认所发现的问题。
 项目负责人向有关人员通报问题及其状态。
 项目软件负责人指定专人解决问题，规定问题更改的完成日期。
 问题更改人员完成问题的更改，并按Q/4MG16.01的规定填写软件更改单。
 由测试人员进行回归测试，证明问题已改，并且未引发新的问题。

3.2.3.4 同行评审平台

    同行评审的目的是为了及早地和高效率地从软件工作产品中消除缺陷。一个重要的伴随结果是对软件工作产品及可防止的缺陷得到更好的了解。军工单位的软件同行评审过程可以归纳为下图所示的6个步骤。

图表 3 19 同行评审步骤

    军工单位可利用ClearQuest完全自主定制的界面和工作流程引擎制定同行评审的的处理流程，包括流程处理状态、流程涉及的数据以及流程涉及的表单布局及设计等。例如，以同行评审的评审申请流程为例，ClearQuest能够从流程电子化到流程可视化借助ClearQuest提供的Designer方便的进行定制，并可以根据自己的需要进行界面的修改，满足自己的使用习惯。

图表 3 20 同行评审平台
3.2.3.5 软件质量保证平台（SQA）

    在整个GJB5000-2003中，SQA是和同行评审一样贯穿所有级别的关键领域，其目的是对过程进行相应的产品审核和活动评审，使管理者对软件项目或组织级活动正使用的过程和正构造的产品有适当的了解。军工单位也正需要这样的平台对一系列工作产品的独立检查，评估其与规格、标准、合约协议或其他规范的符合性。

    IBM Rational的解决方案是针对审计中发现的不符合项、质量问题和客户投诉按照以下4个级别进行分类后，按照逐级升级的过程，结合ClearQuest的过程定制和数据测量达到为产品满足需要的质量提供足够信任的所有活动。

    质量问题的报告及处理可分为A、B、C、D四级进行。其中：

 A级：对SQA审查和审核活动中发现的不符合项的处理
 B级：对在A级预期未解决或未获得项目组明确回复的不符合项的处理
 C级：对在B级未按要求时间获得回复或预期未解决或项目组书面回复无法在项目组范围内解决的不符合项和SQA获得的客户投诉意见的处理
 D级：对C级未按要求时间获得回复或预期未解决或书面回复无法在软件单位范围内解决的质量问题的处理

    在以上基础上，再结合ClearQuest,固化项目检查单，利用如下图3－22所示的CQ灵活的状态机和高度的可定制性,制定CheckList和审计过程,使用CQ对偏差鉴别、形成文件并跟踪至结束.

图表 3 22 SQA平台
4 结束语

    于我们军工单位而言，软件的品质直接决定了军工单位能够提供什么样品质的产品和服务给客户。而软件产品的质量又决定于以下COCOMO II的软件经济学模型所示的因素，所以，在提高军工单位军工软件的的核心竞争能力的道路上我们仅仅只是开始。