707所GJB5000A二级管理平台建设解决方案.doc

《707所GJB5000A二级管理平台建设解决方案.doc》由会员分享，可在线阅读，更多相关《707所GJB5000A二级管理平台建设解决方案.doc（36页珍藏版）》请在麦多课文档分享上搜索。

1、 第 1 页 船舶 707所 GJB5000A二级 管理 平台 建设 方案 第 2 页 目录 船舶 707 所 GJB5000A 二级管理平台建设方案 . 1 1. GJB5000A 二级认证项目背景 4 2. GJB5000A 管理平台总体解决方案 4 3. 基于 RMC 建立可视化的 GJB5000A 过程规范平台 . 6 4. 基于 CQ 的 GJB5000A 流程管理平台 8 4.1. 规范统一的需求获取平台 9 4.2. 缺陷跟踪平台 10 4.3. 同行评审平台 11 4.4. 软件质量保证平台（ SQA） . 13 5. 基于 CC 和 CQ 集成的配置管理平台 15 5.1.

2、实现 GJB5000A CM 过程域 . 16 5.2. 确保软件资产的安全性 17 5.3. 确保软件发布版本的完整性 17 5.4. 将工作产品组织为版本化的构件 18 5.5. UCM 统一变更配置管理机制 . 19 5.6. 维护稳定和一致的工作空间 20 5.7. 支持对构件的并行开发 21 5.8. 确保软件构建的再现性 21 5.9. 有效监控项目质量和状态 21 6. 基于 DOORS、 CQ、 REQTIFY 和 OFFICE 的需求管理平台 22 6.1. 实现 GJB5000A RM 过程域 23 6.2. 需求条目文档化的展现和统一的需求存储中心 23 6.2.1. 文

3、档化需求条目捕 获和展现 23 6.2.2. 基于数据库的需求信息统一管理 24 6.2.3. 多手段高效的需求信息管理能力 24 6.2.4. 需求的基线化管理 25 6.2.5. 及时了解并分析需求变更所带来的影响 26 第 3 页 6.2.6. 测试管理自动化 27 6.2.7. 有效的团队沟通，以保证团队成员都能了解需求信息 28 6.3. DOORS 与 Word 的数据交互 30 6.4. 基于 DOORS 和 Reqtify 的全生命周期需求跟踪 . 30 7. MS Project 和 CQ 的集成的项目管理平台 . 32 7.1. 从 MS Project 连接到 CQ 33

4、 7.2. 输出项目任务到 CQ 中 . 33 7.3. 同步 CQ 任务到 MS Project 项目计划中 . 34 7.4. 同步 MS Project 项目计划任务与 CQ 中的记录 . 35 第 4 页 1. GJB5000A二级认证项目背景 目前国内很多企业都在应用 ISO9000、 CMMI、 6 Sigma 等标准来改进自身的流 程，与这些标准相比，我国的军工企业 武器装备软件 开发大多遵循GJB5000A军用软件 研制 能力成熟度模型 (以下简称 GJB5000A)进行流程改进。 GJB5000A 已于 2008 年 3 月 30 日发布，自 2008 年 6 月 1 日起开

5、始实施。GJB5000A 的制定，旨在引进国外先进的管理经验，提高我国军用软件的质量，它目前已成为我国武器装备软件建设和发展的一项重要标准。 这些 标准所采用的方法和 目标都是一致的，就是要帮助企业不断改进生产工艺，提高产品质量。这些标准本质上都是对质量管理大师戴明的全面质量控制TQC (Total Quality Control) 理论为依据的实践，这些标准各不相同，但是它们殊途同归，都是为了帮助企业提高质量。 在 GJB5000A 中，除了给出了相关于过程成熟度的描述内容外，还给出了改进模式的指导和评估 /评价模式的指导，可以说是一个完全本地化的针对 武器装备软件 开发团队的过程改进体系。

6、 GJB5000A 分五级，第一级是初始级，第二级是已管理级，第三级是已定义级，第四级是定量管理级，第五级优化级，其中第一级不需要认证，第二级已管理级是 GJB5000A 认证的第一个层级，也是我所目前 GJB5000A 认证的目标 。 GJB5000A 体系提供了一个系统的框架，但是它所提供的只是一个过程改进框架，这个框架与软件开发的生命周期无关，更与项目管理的过程无关，因此它并不是企业可以直接采纳的软件开发方法和项目管理方法。在实践过程中还需要具体管理和技术平台的支持。例如对于 GJB5000A 中的每一个目标 (Goal)，GJB5000A 建议了一些关键实践 (Key Practice

7、s)来达到该目标，但这些实践只是提出了在具体实践过程应该注意的事项，并没有列出具体可采用的工程技术。 我们在 GJB5000A 二级过程改进过程中应该如何结合业界 先进的软件工程理论和工具进行过程改进实施并落地生根 ,从而提高 我所 的产品开发中软件工程规范化和整体质量呢？ 2. GJB5000A管理平台 总体解决方案 GJB5000A 包括 RM 需求管理、 PP 项目策划、 SAM 供方协议管理、 CM 配置管理、 PMC 项目监控、 PPQA 过程和产品质量保证、 MA 测 量 与分析 7 个过程域，结合这 7 个过程域涉及到的目标和实践，可以得到以下平台建设需求： 1) 建立 GJB5

8、000A过程管理规范：根据我所实际需求和行业最佳实践经验制定完整的 GJB5000A过程管理规范，包括 过程中涉及到的全部 7个过程域第 5 页 规范，规范 包括 具体阶段划分、每个阶段需要完成的主要任务、参与角色、提交件、主要任务和提交件的评审制度等等。 2) 建立 GJB5000A开发流程管理平台：软件过程管理规范是一个静态的文档性约束，为了保证文档约束得到执行，需要建立一个软件开发流程管理平台，统一存储软件过程中的提交件，统一管理具体工作任务和提交件的评审或审批环节，保证软件过程管理规范得以执行。 3) 具体 GJB5000A技术过程域管理平台：在 GJB5000A二级中的需要使用具体的

9、项目管理平台 (主要管理 项目策划、项目监控、 测量与分析 3个过程域 )、需求管理 平台（管理需求管 理过程域） 和配置管理平台 （管理配置管理平台过程域） 保证过程域的改进。 基于我所目前使用工具的情况和业界工具供应商的情况，我们提出以下解决方案： 1) 基于 IBM Rational Mothod Composer(简称 RMC)定义 可视化的 GJB5000A过程规范 2) 基于 IBM Rational ClearQuest(简称 CQ)将 GJB5000A 过程规范实现在具体工具平台上，负责审批所有过程中的流程和提交件。 3) 基于 IBM Rational ClearCase(简

10、称 CC)建立配置管理平台和统一变更平台， 管理开发过程中的 所有提交件版本变更， 通过 CC 与 CQ 的集成实现 CC 版本变更与 CQ 变更任务的集成，建立 UCM 的配置管理机制 4) 基于 MS Project 建立项目管理平台，同时通过 Project 和 CQ 的集成实现项目计划和具体项目工作内容的关联，实时跟踪项目计划完成情况。 5) 基于 IBM Rational DOORS（简称 DOORS）和 达索 的 REQTIFY 建立需求管理平台， 管理需求分解的过程和对需求进行验证的测试过程， 同时通过 DOORS 和 CQ 的集成实现需求内容和需求管理流程的整合 ，通过DOOR

11、S 和微软 OFFICE 的集成 尽可能维持大家目前的 文档工作习惯 。 具体解决方案如下图 1 所示： 第 6 页 图 1 GJB5000A 管理平台整体解决方案 3. 基于 RMC建立 可视化的 GJB5000A过程规范 平台 。 1. 梳理我所软件开发和管理过程的架构 基于我所已有 的 开发过程规范， 对管理过程开发过程和支持过程按照下图 2所示 ： 的 GJB5000A 的 KPA 架构梳理出策略过程指南和文档（包括模板表单质量记录和检查单等），并以 SEPG 为核心，确立如下图 3 类似的我所过程改进组织架构。G o a lC o . 1 A b . 1 A b . 2 A b .

12、3 A b . 4其 其 其 其 其S E GS C M / S Q AP M S A S AT E S T其 其 其 其 A C . 1 A C . 2 A C . n 图 2 管理过程开发过程和支持过程图 第 7 页 M S G ( 其 其 其 其 其 其 其 )S E P G ( 其 其 其 其 其 其 其 )T W G ( 其 其 其 其 其 )其 其 其 其 其其 其 其 其 其 其 其 其 ( S E P G 其其 )其 其 其 其 其 其其 其 其 其 其 其 其其 其 其 其 其 其 其 其 其 其 其 其 其其 其 其 其 其 其 其 其其 其 其 其 其 其 其 其其 其

13、其 其 其 其 其 其其 其 其 其 其 其 其 其其 其 其 其 其 其 其 其 其 其 其 其 其 其 其 其 其 其 其 其 其 其其 其 其 其 其 其 其 其其 其 其 其其 其 其 其其 其 其 其图 3 过程改进组织架构 2. 导入 RMC 根据我所的产品开发是兼具软硬件开发的系统工程，对于软件开发和管理的改进在以上的基础上可以 利用 RMC 这样的过程改进工具 ，能够轻松地将 我所软件生命周期中的三类过程 ，以及 各种 角色统一整合在一个无缝连接的 过程改进 平台上协同工作。 RMC 可以提供一个 功能强大的 、 可视化的 、易用的 过程 定义工具 ，方便 我所根据项目的实际需

14、要， 定制出自己的 结合 RUP-SE 的 软件项目开发和管理 过程 。 RMC 包含 如下 表 所列 能力： 功能 RMC 益处 提供软件开 发过程平台 RMC是一种软件开发方法论框架，一种经过验证的、灵活而实用的成功软件项目的过程平台： 通过可配置的构架， RMC允许您针对每个软件的每个阶段仅仅选择和部署所需要的过程组件 ； 以业经验证的软件工程最佳经验为核心，RMC平台包括针对项目的特定需要来配置 RUP-SE 的工具、把自己的内部知识开发到过程组件中的工具、强大而且可定制的基于 协助我所快速实现过程改进； 协助我所快速引入软件工程最佳经验； 第 8 页 Web的部署工具，以及与同行及业

15、界权威交流最佳经验的在线社区； 支持业界通用开发及管理过程 RMC 包含了 以下 预定义的 通用过程： 包含了预定义的小项目过程、大的分布式项目过程、系统工程（ System Engineering） 、项目群 (Program)管理和项目组合 (Portfolio)管理过程； 协助我所快速建立所需管理过程； 协助我所快速共享业界最佳经验； 过程的执行能力 定义的过程可以直接转变成 项目计划模板 ， 成功经验帮助团队快速定义项目目标、规划项目资源和确定项目里程碑 ，提高过程的可执行性 ； 协助我所快速完成过程的推广、执行过程； 业务驱动开发过程的支持 通过提供完成的 IT 生命周期管理过程，帮

16、助业务和 IT 部门的有效合作，保持 IT 项目和业务发展目标一致 ； 协助我所快速建立 IT 生命周期管理过程，实现业务驱动的软件开发过程 ，提高 IT的整体投资汇报率 ； 综上所述， RMC 提供给我所的过程可视化解决方案总结如下图 4 所示： 图 4 过程可视化解决方案 每个组织都需要根据自己的业务特点，结合 GJB5000A 构建自己的研发管理体系。纯文字描述的研发管理体系 是一个静态的文本，只是明确了在什么阶段需要做什么事情，且更新维护复杂。 RMC 可以将基于 GJB5000A 的 研发流程以 可视化的定义和发布，并可以定义过程域的具体角色、职责、输入、输出、参考模板等。 4. 基

17、于 CQ的 GJB5000A流程管理平台 我所 GJB5000A 过程规范只是一个静态文档体系，在项目过程中的各种工作流程的流转和提交件的审批需要一个流程管理平台。本平台 符合 GJB5000A 质量保证体系的 要求，将我所 的 软 件过程融入日常项目开发，实现管理与技术的融合，能够有效提高管理效率，降低利用 RMC 定制流程 发布过程至 Web 利用闲散时间学习 利用闲散时间学习 利用过程规划项目 按照过程指导完成项目工作 跟踪和监督过程 执行 跟踪和监督项目执行 跟踪和监督项目执行 结束和总结项目情况，改进 总结，改进建议 SEPG PM/GM MSG TWG/Dev 指导和管理过程改进

18、第 9 页 了理成本，保证产品质量，是一个能够全面、有效管理软件开发的协同工作平台。 其 主要功能 覆盖 ： 需求获取过程管理 缺陷跟踪管理 变更管理 测试管理 软件质量保证（ SQA） 同行评审 软件测量 CQ 是 一个强大而高度灵活的 需求获取、 缺陷 跟踪、 变更 管理和 SQA 审计（ audit） 系统 ，同时又是新一代软件测试管理工具，实现了测试需求、测试用例以及缺陷的集中管理，充分实现了需求团队、开发团队以及测试团队之间信息的共享和团队协作。 我所 可 利用 CQ 完全自主定制的界面和工作 过程 引擎 在 整个开发 生命 周期内 定制自己的开发和管理活动的处理过程，包括过程处理状

19、态、过程涉及的数据以及过程涉及的表单布局及设计等。 同时， 我所 可以通过项目管理、历史记录、附件、审计跟踪、电子签名、 Email通知等几十个预置模型包快速定义用户自己的管理过程。 CQ 除了能对需求、测试、缺陷和审计进行有效的状态跟踪外，还对信息提供了强大的数据查询、统计分析以及报表功能，通过这样的数据测量功能确保项目团队能快速、准确把握软件产品质量、测试进度状况以及团队工作负荷等方面的信息。 CQ 在存储上基于大型关系数据库，如 DB2、 Oracle 和 SQL Server 等，中间件基于 IBM WebSphere 的应用服务器，并提供全中文的 Eclipse 客户端和浏览器客户端

20、，完全满足企业级部署的需求。 利用 CC 和 CQ 的集成活动会自动传 入开发人员工作环境。开发人员以分配给自己的活动为依据进行代码修改，所做修改会自动关联到相应活动。 4.1. 规范统一的需求 获取 平台 有效的项目需求管理的内容包括对需求来源以及需求开发过程的理解，对需求质量的共识，以及需求管理策略。需求信息收集方案主要是针对 我所 的所有已经实施、正在开发和即将开发的产品或项目的以下需求信息进行收集、过滤、分拣、评估、规划、评价： 前版本遗留问题； 用户需求； 版本运行问题； 功能增强性建议，可以来自 用户方 、 开发方或分包方 ； 上级任务。 根据 我所 的用户要求过程中的过程， CQ

21、 帮助 我所 建立 项目团队的需求收集平台，统一需求收集的渠道和信息提交的格式，并遵循必要的需求评估过程，对收集的原始需求进行遴选、分派，同时又能完整保留所有原始需求。 CQ 具有根据客户需求进行灵活定制的能力，有简单易用的 Web 界面，使得由客户和业务人员直接提交原始需求成为可能。如图 5所示，这样的需求获取平台满足并具体化了这个过程的如下目标和关键活动： 第 10 页 1. 目标 用户要求过程活动的目标是针对系统或软件产品提出详细的要求，拟制方案和合同，确定开发单位和验收准则。 2. 输入 过去类似项目数据库 3. 活动 描述对系统或软件产品的要求。 定义和 分析系统需求。系统需求除了应

22、包括设计、测试、标准和过程的描述，还应包括商务、组织结构、用户、安全保密等内容。 如果用户指定开发方分析系统需求，用户应验收经过分析的需求。 用户自己或指定开发方来完成软件需求定义与分析。 需 求 开 发 流 程需 求 发 起 人CQClientReqWebCQWeb提 出 用 户 要 求ReqClient或WordCQClient评 估 、 分 派用 户 要 求接 受 任 务查 看 需 求查 看 需 求 报 告（ 覆 盖 率 ， 追 踪性 ， 优 先 级 ）CQWeb编 写 需 求（ 用 例 规 约 ）发 布 需 求更 新 任 务 状 态用 例 建 模业 务 建 模开 发 人 员查 看 需

23、求查 看 任 务分 析 并 设 置 需 求 属 性建 立 需 求 追 踪 关 系需 求 沟 通 、 评 审查 看 任 务 完 成 情 况需 求 分 析 员业 务 人 员图 5 需求获取平台 4.2. 缺陷跟踪平台 借助 CQ 建立的缺陷跟踪平台与 DOORS 集成可以帮助我们： 跟踪需求和缺陷 建立需求到测试、缺陷的追踪关系，实现软件开发的闭环 第 11 页 图 6 缺陷跟踪 平台 4.3. 同行评审平台 同行评审 的目的是为了及早地和高效率地从软件工作产品中消除缺陷。一个重要的伴随结果是对软件工作产品及可防止的缺陷得到更好的了解。 我所 的软件同行评审过程（ Q/4MG16.08 2005）

24、可以归纳为下图 7 所示的 6 个步骤 。 测试人员创建与原有需求相关的测试用 例 第 12 页 评 审 策 划（ P l a n n i n g ）工 作 产 品 纵 览( O v e r v i e w )评 审 前 准 备( P r e p a r a t i o n )召 开 同 行 评 审 会 议( P e e r R e v i e w m e e t i n g )返 工( R e w o r k )跟 踪 、 验 证( F l l o w u p )再 次评 审 反 复图 7 同行评审步骤 我所 可利用 CQ 完全自主定制的界面和工作流程引擎 制定同行评审的 的处理流程，包括流

25、程处理状态、流程涉及的数据以及流程涉及的表单布局及设计等。 例如，以 3327 同行评审的评审申请流程为例， CQ 能够从 流程电子化到流程可视化借助 CQ 提供的 Designer 方便的进行定制， 并 可以根据自己的需要进行界面的修改，满足自己的使用习惯。 第 13 页 其 其 其 其其 其 其 其 其 其 其 其 其 其 其 其 其 其 其 其 其 其 其 其其 其 其 其 其其 其 其 其 其 其其 其 其1 . 其 其 其 S u b m i t 其其 其 其 其 其 其其 其 其 其 其 其其2 . 其 其 其 其 其 其 其 其 其 其其 其 其 其 其 其 其其 其 其 其 其

26、 其其3 . 其 其 其 其 其 其 其 其其 其 其 其 其 其 其4 . 其 其 其 其 其 其 其 其6 . 其 其 其 其 其 其 其 其其 其 其 其 其 其 其其 其 其 其 其 其其6 . 其 其 其 其 其 其 其 其其 其 其 其 其 其 其其 其 其 其 其 其其5 . 其 其 其 其 其 其 其其 其 其 其 其 其 其其 其 其 其 其 其图 8 同行评审平台 4.4. 软件质量保证平台（ SQA） 在整个 GJB5000-2003 中， SQA 是和同行评审一样贯穿所有级别的关键领域，其目的是第 14 页 对过程进行相应的产品审核和活动评审，使管理者对软件项目或组织级

27、活动正使用的过程和正构造的产品有适当的了解。 我所 也正需要这样的平台对一系列工作产品的独立检查，评估其与规格、标准、合约协议或 其他规范的符合性。 本 解决方案是针对审计中发现的 不符合项、质量问题和客户投诉按照以下 4 个级别进行分类后，按照图 9 中所示的过程，结合 CQ 的过程定制和数据测量达到为产品满足需要的质量提供足够信任的所有活动。 质量问题的报告及处理可分为 A、 B、 C、 D 四级进行。其中： A级：对 SQA审查和审核活动中发现的不符合项的处理 B级：对在 A级预期未解决或未获得项目组明确回复的不符合项的处理 C级：对在 B级未按要求时间获得回复或预期未解决或项目组书面回

28、复无法在项目组范围内解决的不符合项和 SQA获得的客户投诉意见的处理 D级： 对 C级未按要求时间获得回复或预期未解决或书面回复无法在软件单位范围内解决的质量问题的处理 ADB?S Q A ? / ? / ?BC?C? S Q A ? , ? 4 ? ? ? , ? , ? S Q A ? ? S Q A ? ? , ? S Q A ?S Q A ? ?S Q A ? , ? 4 ?图 9 质量问题的报告及处理 在以上基础上，再结合 CQ,固化项目检查单， 利用 如下图 10 所示的 CQ 灵活的状态机和高度的可定制性 ,制定 CheckList 和审计 过程 ,使用 CQ 对偏差鉴别、形成文

29、件并跟踪至结束 . 第 15 页 图 10 SQA平台 5. 基于 CC和 CQ集成 的配置管理平台 SQA 组按照 SQA规程审查软件工程活动以证实符合性 SQA 组审核指定的软件工作产品以证实符合性。 利用 CQ 灵活的状态机和高度的可定制性 ,制定 CheckList 和审计 过程 ,使用 CQ对偏差鉴别、形成文件并跟踪至结束 . 第 16 页 基于 GJB5000-2003 和 GJB2786-963327 质量保证体系的我所的管理类、开发类和支持类的所有过程都强调或遵守对工作产品和变更“进行管理和控制”，正如图 11 所示。这意味着在给约定时间（过去或现在）使用的工作产品的版本是已知

30、的（即版本控制），而且以受控的方式引进更改（即更改控制）。但是正如我们面临的问题那样，如果没有对过程支撑的相对应的工具平台，过程实施每一个环节将很难落到实处。 配置管理平台 正好作为一种特定的工程技术解决方案为 我所的软件配置管理（以下简称SCM）过程提供了一种具体可操作的实践手段。 支 撑 平 台过 程 财 富开 发 类支 持 类管 理 类软 件 配 置管 理 过 程文 档 过 程软 件 同 行评 审软 件 确 认过 程软 件 质 量保 证 过 程培 训 过 程组 间 协 调过 程软 件 问 题处 理 过 程S P D BC l e a r C a s e C l e a r Q u e s

31、 t用 户 要 求过 程软 件 项 目计 划 过 程软 件 项 目控 制 过 程软 件 需 求过 程软 件 设 计过 程软 件 编 码过 程软 件 测 试过 程软 件 综 合过 程软 件 度 量过 程支 撑支 撑受 控测 量U C M管理支持图 11 配置管理 平台 解决方案 5.1. 实现 GJB5000A CM过程域 本配置 管理 平台可以实现 GJB5000A 二级 CM 过程域的以下目标 : 识别纳入基线的配置项 配置项变更控制 第 17 页 配置库控制规范 维护基线完整性 报告配置项状态 5.2. 确保软件资产的安全性 配置管理平台 解决方案 的首要任务，就是要在安全的存储库中对 工

32、作产品 进行正确的标识和存储，从而进行有效的版本控制。需要标识和存储的 工作产品 包括：项目计划、需求文档、设计模型，源代码、库文件、可执行文件、 Web 内容、测试计划、测试用例、测试脚本等等。对 工作产品 进行正确标识的目的就是确保在需要时能够简单、快速地找到它们的正确版本。 配置管理平台 解决方案 实现以下功能 : 对软件开发过程中的全部 工作产品 进行版本化管理，包括代码、各种文档、目录模型、测试脚本、图形和各种二进制文件等； 在安全的存储库中进行 工作产品 的标识和存储，安全的存储结构和灵活的权限设定，杜绝了任何未经授权的变更，保证了 我所 软件资产的安全，有效保护 我所 的核心资产

33、。 控制并审计对 工作产品 的变更：在标识和存储 工作产品 的基础上， 配置管理平台 解决方案还对 工作产 品 的变更提供有效的控制手段和审计能力。控制对 工作产品 的变更指的是能够设定谁能够对哪些 工作产品 进行修改；对 工作产品 的变更进行审计指的是能够记录与 工作产品 修改相关的所有操作历史信息记录：包括谁进行的修改，修改了什么，什么时候进行的修改，为什么要进行修改？ 图 12 配置管理平台 解决方案 确保 我所 资产安全 5.3. 确保软件发布版本的完整性 配置管理平台 解决方案 中的 CC 使用标签来标记某一特定的基线，如图 13 所示，标签可以是任意的字符串： 第 18 页 图表

34、错误 !文档中没有指定样式的文字。 -1 配置管理平台 解决方案 确 图 13 基线图 在项目里程碑创建正确的基线和完善的基线管理，可以确保设计与需求的一致性、代码与设计的一致性、使用正确的代码进行发布等。适时创建基线有以下好处： 可重现性：有能力准确回到任何一个先前的软件版本。 可追踪性：保持项目需求、项目计划、测试用例等与源代码之间的一致性和可追溯性。 配置状态报告：有了适时创建的基线，就可以查询、报告、比较基线的内容。 5.4. 将工作产品组织为版本化的构件 所谓版本化的构件就是一组 相关的文件和目录，这些文件和目录作为一个单一的单元进行版本控制、基线管理、编译 /构建，共享和重用。将

35、工作产品 组织为版本化的构件有以下好处： 降低复杂性：构件通过提高抽象层次来有效降低复杂性，使得问题更加易于管理。 标识构件的质量水平比标识单个文件的质量水平更有意义； 详细地记录了配置管理行动， 每个配置项 /单元都能恢复到以前的任何一个版本。 每个配置项 /单元的内容和状态都是清楚的 ,包括 : 创建信息 分支信息 版本信息 基线信息 归并信息 任务信息 第 19 页 有利于共享和重用； 图 14 版本化的构件 5.5. UCM统一变更 配置 管理 机制 变更请求有多种形式并且来自不同的地方，如来自内部及外部的错误报告；来自业务及工程部门的功能增强请求；需求、设计、及文档变更请求，等等。我

36、们不仅需要一个合理的过程 来对变更请 求进行记录和跟踪，可能的话，还应该对实现变更请求而造成的相关 工作产品 的变化结果进行跟踪。 如图 15 所示的 统一变更管理的提供了以活动为中心的软件开发过程的组织和协作，自动为每个开发活动维护一个一致的变更集，基于活动可以对其变更集进行统一的检出、检入、集成、编译和建立，从而有效组织了统一变更管理的三个基本要素：人、活动、 工作产品 ，准确标识当前发布包含哪些新功能、当前发布对已有功能进行了哪些增强、当前发布修复了哪些缺陷等。 第 20 页 图 15 统一变更管理平台 5.6. 维护稳定和一致的工作空间 维护稳定和一致的工作空间是实现并行开发、提高开发

37、效率的必要前提。存在两类工作空间，一类是开发人员的私有空间，在私有空间中，开发人员可以相对独立地编写和测试自己的代码，而不受团队中其他开发人员工作的影响，即使其他人也在修改同样的文件；另一类工作空间是团队共享的集成空间，该空间用于集成所有开发人员的开发成果。 所谓工作空间的稳定性指的就是私有空间的相对独立性，在私有空间中，开发人员可以相对开发人员 综合 人员 测试人员 项目 负责人/SCCB 变更 打开 分配 测试 关闭 变更 分析人员 开发活动 开发活动 优先级 责任人 项目 登录网站中文化 1 Sam CRSDC 欢迎界面没有小标题 3 Sandy CRSDC 加入 GUI 按钮 1 Ki

38、m CRSDC 对每个配置项 / 单元都能维护其当前状态和历史（即变更和其它行动）。 集成人员 版本历史 版本状态 版本号 版本关联的开发任务 版本变更集 第 21 页 独立地编写和测试自己的代码，而不受团队中其他 开发人员工作的影响。每个开发人员都有自己的私有工作空间，不同开发人员的私有工作空间是相互独立、彼此隔离的。所谓工作空间的一致性指的是当开发人员对自己的私有空间进行更新时，得到的应该是一个可编译的、经过一定测试的一致的版本集。 5.7. 支持对构件的并行开发 传统的串行开发模式在同一时间只允许一个人对同样的文件进行修改，其他需要修改同样文件的人只能等到前面的人修改完成后再开始自己的修

39、改，这样的好处是不会出现修改上的冲突，但在当今的市场环境下，这种串行开发模式显然是行不通的，因为它既不现实、也缺乏效率，取而代之的是并行开 发模式。具备强大的分支和自动化合并的能力，以有效支持并行开发，提高开发效率。 1C o m p o n e n t : R E L 服务器R E LR E L 2 0 0 4 _ I n tR E L 2004_devR E L 2 0 0 4 _ I n tR E L 2 0 0 4R E L 2 0 0 5正式运营测试开发2预运营R e l e a s e 2R e l e a s e 3分支生成R e l e a s e 1归并图 16 配置管理平台

40、 解决方案 提供的软件并行开发能力 5.8. 确保软件构建的再现性 有时出于排错的需要，或需要重现相同的构建（ Build），我们需要知道软件是如何被构建的，构建中包含哪些内容，这就要求配置管理系统提供构建审计功能。 构建审计功能应能自动记录以下内容：谁执行的构建？什么时候执行的构建？构建生成的可执行文件或库包含哪些内容？执行构建的机器是什么？机器上运行的操作系统版本是什么？执行构建使用的是什么编译器？使用了编译器的哪些选 项？等等。有时候仅仅改变编译器的优化选项开关就可能引入新的错误，有了构建审计功能，就有可能进行不同构建的比较，从而有利于排错。缺乏软件构建的再现能力就很难进行软件系统的维护

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

42、量的监控 6. 基于 DOORS、 CQ、 REQTIFY和 OFFICE的需求管理平台 我所 通过使用 DOORS、 CQ、 REQTIFY 和 OFFICE 搭建的需求管理平台，实施有效的软件配置及变更管理后可以循序渐进地解决 我所 目前软件开发中的存在问题： 进行测量并将测量结果用于确定 SCM活动的状态。 单位时间处理的更改申请数； SCM 活 动 里 程碑的完成情况与计划比较； 在 SCM 活动中完成的工作、开销的工作量和资金。 第 23 页 如何遵循 GJB5000A成熟度第二级的 RM关键过程域进行有实效的改进的最佳实践 ; 目前的需求管理松散 ,没有 完整的需求捕获和管理 体系

43、 ; 没有需求变更管理 ,造成无法有效记录并跟踪变更请求 ; 无论是技改项目还是产品开发都存在较严重的不受控的需求变更 ，造成最终形成的产品无法和原始需求对应 ; 对于用户 的需求难以正确有效的获取 ; 不规范的需求描述 和需求无法条目化，造成需求理解的偏差 ; 缺乏需求属性的定义，难以以不同视角展现需求，如需求风险大小，需求优先实现级别等 ; 缺乏需求到设计建模、需求到测试的追踪能力，使需求的实现验证无法得到保证 ; 无 法对需求基线化管理，不了解不同的需求基线差异 ; 针对以上存在的问题 ,我所 如何结合 GJB5000A 中的 RM 关键过程域切实有效的进行改进 ?我们认为 需求管理平台

44、可以 结合 我所 自身具体实际 助力我们符合 GJB5000A 成熟度等级 2 中 RM 关键过程域的要求。而且在更深层次上解决软件需求管理中的问题。 6.1. 实现 GJB5000A RM 过程域 本需求管理台可以实现 GJB5000A 二级 RM 过程域的以下过程实践 : 需求可理解 需求确认 管理需求变更 需求可追溯 保证需求与后续工作产品之间的一致 6.2. 需求条目文档化的展现和统一的需求存 储中心 6.2.1. 文档化需求条目捕获和展现 在任何高效的需求管理过程中，需求捕获和记录是需求管理成功的关键一步。这可以确保对不断发展的需求进行准确地交流与管理。文档是记录需求、提供上下文或补

45、充需求信息的最佳格式， 我所 的需求管理解决方案利用了广泛使用并为人熟知的 Microsoft Word 工具来简化需求信息的捕获。见下图 ： 第 24 页 6.2.2. 基于数据库的需求信息统一管理 虽然文档有助于需求信息的捕获，但它并不是对信息进行优先级划分和管理的最优环境，为保证这些活动的执行， 我所 的需求管理方案还提供了统一的需求存储中心，通过将需求文档链接到统一的存储中心， 我所 的需求管理解决方案平滑地将文档与数据库的优点统一起来。 这样需求管理团队可以在所熟知的 Microsoft Word 环境中修改，浏览需求信息，同时 Word 文档中的需求信息动态链接到存储在数据库中的补

46、充需求信息，从而使得需求管理团队实现需求优先级划分，链接需求并跟踪变更，见上右图。 6.2.3. 多手段高效的需求信息管理能力 通过指定如优先级、难度和状态等属性，可以帮助团队某种程度上实现紧靠使用文档所不可能完成的需求信息管理工作， 我所 需求管理解 决方案提供了现成的标准属性和属性值，同时可以帮组团队轻松自定义，以支持团队的需求处理过程和术语。 结合数据库和 Word 的特点， 我所 需求管理方案可以提供组织、排序、过滤和跟踪需求信息的方法，从而提高团队成员间的交流，团队的协作能力和第 25 页 降低项目风险，见下图。 6.2.4. 需求的基线化管理 用户可以在 DOORS Baselin

47、e Manager 中以项目、包、视图或跟踪矩阵为对象建立需求规格说明基线，并且可以比较基线并根据基线再生项目。 生成基线基线打包需求 10 批准的 低 高 高 客 户 户 需求 13 被提议 中等 低 低 用户 需求 40 强制的 高 高 高 用户 $ $ $ 状态 风险 优先级 工作量 成本 稳定性 来源 高 客户 第 26 页 6.2.5. 及时了解并分析需求变更所带来的影响 在开发过程中，需求变更是不可避免的，因为它表明了项目的渐进明细的特点，但是如果缺乏管理的需求变更则会使项目慢慢偏离需求所要满足的系统特征和需要。 我所 需求管理解决方案可以 : 通过对需求分类，创建不同类型的需求链

48、接关系，可以轻松地确定并分析需求变更所带来的影响。通过跟踪矩阵，跟踪树等功能，当某种需求发生变化时，可以很容易地看出它对其他需求的影响，可以查明需求变更对整个项目的影响并评估影响范围，以便进行核实和确认。利用这种分析变化影响的能力，管理 团队可以做出快速明智的决策，进行范围管理后资源重分配。见下图 第 27 页 每个需求项的版本记录能力，使得需求管理团队可以方便查阅需求变更历史过程。随着需求的发展，所做的每一个修改都会被捕获跟踪并全部存档于需求管理平台中。需求审核跟踪将把谁，什么，为什么和什么时候修改的需求进行存档，帮助需求管理团队分析它对整个项目的影响。见下图 6.2.6. 测试管理自动化 测试管理是指对系统测试活动的管理，其主要目的是测准（有效选择 运行测试用例，发现系统的缺陷）和测全（保证所有需求对被测试过）。 不同阶段的