软件配置管理规范流程

1 概述

1.1 目的

本文档主要目的在于规范项目配置管理活动，确保配置项正确地唯一标识并且易于存取，保证基线配置项的更改受控，明确基线状态，在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。

1.2 适用范围

本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动，针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法，本文件以CVS（并行版本系统）配置管理工具为例，规定公司的配置管理办法，使用其他工具时也可对应本文件的要求参照执行。

1.3 术语和缩略语

1.3.1 软件配置管理（Software Configuration Management，SCM）

软件配置管理是对软件修改进行标识、组织和控制的技术，用来协调和控制整个过程。是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。

1.3.2 配置项（Configuration Item，CI）

凡是纳入配置管理范畴的工作成果统称为配置项，配置项逻辑上组成软件系统的各组成部分，一般是可以单独进行设计、实施和测试的。

每个配置项的主要属性有：名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。

1.3.3 基线（Baseline）

在配置管理系统中，基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，这些配置项构成了一个相对稳定的逻辑实体，而这个过程被称为“基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素（配置项）的一个版本，且只确定一个版本。一般情况下，基线一般在指定的里程碑处创建，并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制，基线中的配置项被“冻结”了，不能再被

任何人随意修改，对其修改要严格地按照变更控制的过程进行。在一个软件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一个基线。

基线的主要属性有：名称、标签、版本、日期等。

1.4 权限与职责

1.4.1 研发总经理助理

1）审核变更请求。

1.4.2 项目经理（Project Manager，PM）

1) 审核批准配置管理计划；

2) 接收或拒绝小范围的变更申请；

3) 召集评估变更；

4) 提出配置管理的建议和要求；

5) 配合配置管理员的工作。

1.4.3 配置管理员（Configuration Management Officer，CMO）

1) 编写配置管理计划；

2) 执行版本控制和变更控制方案；

3) 制定访问控制策略；

4) 负责项目的配置管理工作，包括搭建环境、权限分配、配置库的建立、配置项的控制等；

5) 配置管理工具的日常管理与维护；

6) 配置库的日常操作和维护；

7) 负责配置审核并提交报告；

8) 根据配置部署表单编译发布版本，并维护版本；

9) 对开发人员进行相关的培训；

10) 对配置审核中发现的不符合项，拟订纠正措施，要求相关责任人进行纠正。

11) 监督项目组成员规范的执行情况。

1.4.4 开发人员（Developer）

1) 根据确定的配置管理计划和相关规定，提交配置项和基线；

2) 负责项目组内部测试；

3) 负责软件集成和版本生成；

4) 按照软件配置管理工具的使用模型来完成开发任务。

2 实施细则

2.1 配置项管理

2.1.1 配置项的范围

软件配置可包括以下几方面：开发文档，代码，第三方控件、插件，参考资料，测试文档，用户文档，项目管理文档，验收文档等。

l 项目文档主要指：立项建议书、可行性分析报告、技术建议书、用户需求说明书、项目计划、项目进度计划、项目阶段性计划、产品需求规格说明书、概要设计报告、详细设计、数据库设计、界面设计、用户操作手册、用户安装手册、培训文档、验收报告以及上述文档的评审记录。

l 代码主要指：源代码等。

l 工具主要指：脚本文件、插件、第三方控件等。

2.1.2 配置项基线管理

结合SPP和ISO9000的相关规定，配置管理员根据配置管理规范及配置管理计划，对配置项进行分阶段管理，每一阶段正式评审通过后纳入受控库，作为该项目的一个基线。

l 项目启动：配置项包括技术建议书、可行性分析报告、用户需求说明书等立项阶段产生的文档，评审或审批通过后建立发布基线。

l 需求阶段：系统调研后开发人员进行需求分析，并整理产品需求规格说明书。产品需求规格说明书经过客户的确认后，建立需求基线。如需升级版本则必须通过评审或审批并得到客户的确认。

l 项目计划：需求分析完成后即可制定项目的开发计划，包括项目计划和主要下属计划。包括项目进度计划、配置管理计划、质量保证计划、测试计划、项目阶段性计划。项目开发计划评审通过后，建立项目计划基线。

l 设计：系统设计可分为概要设计、详细设计、数据库设计、数据库字典、界面设计。针对用户需求规格说明书进行系统设计，配置时应说明系统设计的版本与需求分析报告版本的对应关系。设计说明书评审或审批通过后，建立设计基线。

l 编码（设计实现）：编码按功能模块分子项目，即每个模块记作一个配置项。代码在提交项目组系统测试时建立Beta版本，系统测试产品正式发布后建立Version版本。

l 测试：单元测试和系统测试。单元测试通过提交《单元测试报告》，项目启动后应提交《系统测试计划》，系统测试完成后应提交《系统测试报告》。配置时应说明测试的版本与编码版本的对应关系。系统测试完成后建立测试基线。

l 版本发布：项目组提交《部署表单》，CMO根据部署表单进行编译，发布测试服务器上，并对版本进行维护。同时将发布的版本上传到文档服务器上备份。

l 交付与验收：在交付前配置审核完成后建立产品基线，产品基线包含程序以及有关文档配置项，包括交付文档、代码、工具等。

l 产品部署：部署时应包括操作手册、安装维护手册、维护文档以及必要的业务和技术培训文档。

l 相关资料：相关资料也应作为配置项纳入配置管理，此部分包括：

1) 相关法律、法规；必须遵照或项目组约定的技术规范；

2) 与客户或项目组内部重要的交互信息记录，如会议记录、会谈记录、e-mail 和MSN记录等；

2.2 版本控制

2.2.1 文档的版本控制

所有文档的管理纳入配置管理库，用版本控制工具进行统一管理。文档的版本控制主要通过文档的名称、文档控制页及版本控制工具的标签来实现，主要分为以下几类：

2.2.1.1 版本变化型文档

命名方式：[文档名称]+[子系统名称]（可选）

适用文档：项目计划、配置管理计划、质量保证计划、项目进度计划、用户需求规格说明书、产品需求规格说明书、体系结构设计报告、数据库设计报告、详细设计报告、用户操作维护手册、测试用例等。

示例：项目计划.doc

详细设计_SP门户.doc

标签结构：[大版本] + [子系统简称] + [版本号] + 日期（标签控制说明版本信息）

l [大版本]：可选，表示同一项目为不同用户定制的版本。

l [子系统简称]：可选，当一个项目有多个子系统时，为区分不同子系统而设置。

l [版本号]：采用[Vs_x_y]的形式。

l 日期：纳入基线管理的日期，用8位表示，如20071031

说明：

a. 文档发布名称采用[文档名+ Vs_x_y]的形式，文档的版本号应该和版本控制工具中相应标签上的版本号一致。

b. 对文档的修改需要从配置管理库中取到本地进行。

c. 对于文档小的修改，如文字错误，格式调整，变更Vs_x_y中的y来区别（如：V1_0_1）。

d. 文档内容没有大的增加和删节，意思表述没有发生重大的变化，版本标识通过版本工具中加上x标签来表示（如：V1_1_0），以及在文档内部控制页标注变化来表示。

e. 文档有重大增加和删节，意思表述有重大变化的，版本标识通过在相应文档加上s标签来表示（如：V2_0_0）。

f. 对于纳入基线库的文档的修改需要提交变更申请，经批准才能进行修改，并且修改的内容要经再次评审才能重新纳入基线库，作为后续阶段的参考文档。

2.2.1.2 时间区别型文档

命名方式：[文档名称＋撰写时间]

适用文档：文档名称有明确的含义，需要用时间标识的日常性文档。如周例会会议纪要，项目月计划，项目月总结,阶段性计划等等。

示例：周例会会议纪要20030901.doc

2.2.1.3 时间序号型文档

命名方式：[文档名称+人员姓名（拼音）+撰写时间+序列号]

适用文档：测试报告

示例：单元测试报告_lixiaohong_20071112_01.dco

2.2.1.4 其他文档：

对于不能按照前四种类型进行命名的文档

会议纪要：会议纪要YYYYMMDD ( )

示例：9月9日召开的项目启动会

命名为：会议纪要20030909(项目启动).doc

评审报告：评审报告YYYYMMDD ( )

同”会议纪要”要求一致。

示例：10月9日召开的项目总体方案评审

命名为：评审报告20030910(总体方案).doc

2.2.2 发行版本表示

发行版本采用标签说明，结构如下：

[大版本] + [版本类型] + [版本号] + [子系统简称(拼音)]+日期+序号

[大版本]：可选，表示同一项目为不同用户定制的版本。

[子系统简称]：可选，当一个项目有多个子系统时，为区分不同子系统而设置。

版本类型：分为3种

Beta表示项目组内部测试，标签：B1_0_0-20071015-01

Release系统测试，标签：Release1_0_0-SPmenhu-20071112-01

Version正式发行版，标签：Version1_0_0-SPmenhu-20071112-01

[版本号] 对于Version正式发行版是必须要注明的，而其它可选。

发行产品基线在版本号前加Version，如

Version_1, Version_2, Version_3….表示分支；

Version_1_0, Version_1_1, Version_1_2…表示在分支Version_1上的标签；

Version_0_0, Version_0_1, Version_0_2…表示在主线上的标签。

2.3 配置库管理

2.3.1 配置库的分类

配置库统一由配置管理员负责管理，服务器端使用cvsnt2.0.4，客户端主要使用乌龟CVS。配置库目录结构如下：

2.3.2 配置库的建立

所有项目应建立配置库，以便管理各配置项，配置管理员组织建立配置库。程序库主要通过设置版本的分支来实现对配置项权限管理：

1)开发库：开发人员相对比较自由的存储空间，开发人员可以在自己的权限范围内任意取出提交。

2)基线库：配置管理员有最高权限，其余相关人员均为读的权限，发生变更时变更人员须提交变更申请后方可修改基线库内的配置项。

? 文档评审通过后，文档严格受控。由配置管理员将通过评审后的文档移植到基线库里同时将该配置项从开发库移除。

? 代码一般在移交系统测试时纳入基线库受控，可根据项目的具体情况设置基线。

3)产品库：产品库的产品均出自于基线库，产品库存储的产品用于交付和存档。

配置三库统一由配置管理员管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。

2.3.3 分配权限

项目开始后配置管理员编写《配置库目录结构表》明确项目组成员以及相关人员的权限。在wincvs里有三种权限，读（r）、写（w）、添加删除（c）权限。在开发库内，文档部分项目组成员有rcw权限，其他相关人员只r权限；代码部分项目组成员有rcw权限，其他相关人员没有任何权限。在基线库内，项目组成员仅有r权限，其他相关人的权限视情况而定。在产品库内，所有人没有任何权限。配置管理员在三库内均拥有最高权限。

2.4 配置变更控制

2.4.1 变更的分类

软件及其相关文档的变更按照变更的影响范围进行分类：

1)A级：变更会影响系统级的需求、外部接口、产品价格或者交付期；这类变更必须经过配置管理委员会审核并有客户批准和确认。

2)B级：变更会影响配置项间的功能接口、内部功能的设计、组件；这类变更必须由项目经理或配置管理委员会的批准和认可。

3) C级：变更只会影响配置项内部或对BUG问题的处理；这类变更可以由配置项的管理人员负责批准。

? 系统测试前变更控制流程：

? 系统测试完毕发布release版本后变更控制流程

图2 变更控制流程

2.4.2 变更请求的提出

a．由技术支撑中心汇集顾客意见，影响到需求变更则填写《配置项变更控制报告》，并提交给配置管理员。

b．配置管理员对申请表是否清晰、明确和完整性进行审查，若发现变更不明确或不完整，应返回申请者。对通过审查的变更申请分配变更ID，以便跟踪和记录变更信息。

2.4.3 评估变更

a．配置管理员将《配置项变更控制报告》发送给项目经理（或者其他授权人员），由项目经理负责对变更进行评估。

b．项目经理对变更进行分解，一般的BUG修正不需要审批直接由项目经理决定是否需要变更。新增功能或对整个项目影响重大的变更必须由研发总助审批通过后方可变更。变更评估文档在完成变更评估后发送给配置管理员。

2.4.4 变更实施和确认

a．变更被批准后，项目经理提交变更实施进度计划，开发人员开始实施变更，并详细记录变更的内容；质量部对变更的实施进行跟踪。

b．对于代码变更，必须进行回归测试，以确保变更没有引入新的Bug。另外与变更相关的文档必须修订，以反映变更。当变更以及测试完成后，进行提交。

c．通过测试后，质保人员需对变更进行审核，审核的范围一般涉及以下方面：测试记录；变更请求；配置项的检入及检出；文件的命名；版本的编号。

a．审核后，由配置管理员更新到基线库中。

2.5 配置状态报告

2.5.1 目的

记录和报告整个软件生命周期演化状态。

2.5.2 记录内容

配置状态报告记录的内容包括：

1) 软件和文档的标识；

2) 目前状态；

3) 基线演化状态；

4) 变更状态；

5) 版本交付信息等。

2.5.3 生成报告

配置管理报告自第一个基线创建时建立，由配置管理系统生成，及时反映当前配置状态。

2.6 配置审核

2.6.1 类别

配置审核分为：

1)功能配置审核（Functional Configuration Audit，FCA）：审核软件功能是否与需求一致，并符合基线文档要求，通常要审查测试文档等。

2) 物理配置审核（Physical Configuration Audit，PCA）：审核要交付的组成项是否存在，是否包含所有必需的项目，如正确版本的源代码、资源、文档、安装说明等等。

2.6.2 执行时机

通常选择以下几种情况由质量保证人员负责实施配置审核：

1)软件产品交付或是软件产品正式发行前；

2)软件开发的阶段工作结束后；

3)在产品维护工作中，定期地进行。

2.6.3 不符合项处理

对配置审核中发现的不符合现象，配置管理员进行记录，并交由责任部门限期进行纠正，配置管理员负责纠正措施的验证。所有的不符合项报告均关闭后，才能发布新版本。

2.7 发行管理

通过配置审核后，经项目经理批准，由配置管理员负责生产新版本。

2.7.1.1 交付管理

这里“交付”是指从配置库中提取配置项，交付给客户或项目外的人员。交付出去的配置项必须有据可查，避免发生混乱。流程如下：

1)交付人向质量部申请；

2)质量部如果不同意交付，则拒绝交付配置项。如果同意交付，配置管理员应给出详细的交付清单；

3)交付人验收后签字。

软件配置管理过程指导说明书(超级实用)

软件配置管理过程指导说明书

目录 1 前言 (2) 1.1 目的 (2) 1.2 适用范围 (2) 1.3 术语名词解释 (2) 2 角色和职责说明 (3) 3 输入 (4) 4 入口准则 (4) 5 配置管理实施 (4) 5.1 配置库结构 (4) 5.1.1 配置库 (4) 5.1.2 配置管理库系统 (6) 5.2 配置管理流程 (6) 5.2.1 配置管理流程图 (6) 5.2.2 配置变更流程图 (7) 5.3 配置标识 (8) 5.3.1 配置库划分 (8) 5.3.2 配置库结构 (8) 5.3.3 配置项命名 (11) 5.3.4 版本编号规范 (11) 5.4 配置管理活动 (12) 5.4.1 制定配置管理计划 (12) 5.4.2 建立配置库 (12) 5.4.3 建立配置项 (12) 5.4.4 基线建立及发布过程 (12) 5.4.5 配置变更 (13) 5.4.6 配置审计 (15) 5.4.7 备份 (16) 6 输出 (16) 7 出口准则 (16) 8 本过程裁剪规定 (16)

1 前言 1.1 目的 用于描述配置管理作用和过程，规范配置管理的实施过程、活动和操作。 1.2 适用范围 适用于在软件生命周期中对各类软件项目的配置管理活动。 1.3 术语名词解释 CCB：Configuration Control Board，配置管理委员会，每个项目组需要建立项目级的CCB作为变更控制权威。CCB由质量工程师、项目经理、测试经理、配置管理员构成，有时也可以包括客户代表、上级质量部门主管。CCB组长可以是质量工程师或质量部领导，但不能是项目经理。 软件配置项：是指软件工程过程中所生产或使用的任何元素，或者是纳入软件产品的元素。它可以是说明书、计算机程序、数据结构或者开发软件产品所使用的工具等，包括：项目文档，源代码，执行程序，相关设备及资料。 软件配置管理：对软件配置项的管理称为软件配置管理。软件配置管理的目的是建立和维护软件项目整个生命周期中工作产品的完整性和可追溯性。 软件工作产品：由定义、维护和使用一个软件过程所产生的任何人工制品，包括过程描述、计划、规程、计算机程序和相关文档，无论是否打算将它们交给客户或最终用户。 软件产品：可交付给客户或最终用户的软件工作产品的子集称作软件产品 基线：基线，是开发过程中标识出的里程碑所交付的一个或多个配置项，也即指一个（或一组）配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态它有如下特征：（1）已经过正式的评审和批准；（2）作为项目发展和产品升级的基础。（3）基线变更必须经过CCB审批。 变更控制：对配置项的更改进行评价、协调、认可或不认可以及执行更改的过程。 版本发布：指从项目的配置库中将需交付给客户的所有配置项组装成一个完整的软件产品。即交付给客户的一个包括可执行程序和文档的发布基线称为发布（release）。 配置审计：可以分为物理审计和功能审计。物理审计审查配置项的外在特征的正确性与一致性，主要考查软件受控库的结构、内容及其它相关信息，以验证基线和描述它的文档的一致性；功能审计审查配置项内容的正确性与一致性，主要考核配置项在实现功能上的一致性，功能审计主要通过评审和测试报告体现。 物理审计的内容包括： ? 确认配置项标识的正确性； ? 确认已受控配置项的更改是受到控制的； ? 验证配置库内容与相应记录之间的一致性； ? 验证配置管理活动与相应记录之间的一致性； ? 验证配置管理工作是否符合适用的标准和规程； ? 验证配置管理系统与系统备份的有效性、一致性等。 功能审计的内容包括： ? 验证当前基线所含配置项对前一基线所含配置项的追溯性； ? 确认当前基线所含配置项均正确反映了项目需求； ? 评估基线的完整性； ? 验证当前基线和各基线间所含配置项的一致性； 验证配置库内容的完备性和正确性等。

软件版本管理规范标准[详]

软件版本管理规 第一章目的 本规详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等容，使软件项目版本管理流程化并规化，确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，本文所述使用的是SVN）进行版本管理。 2.第三章职责 配置库管理员：负责配置库的日常维护和管理；监督开发及测试部门及时提交版本管理对象（即配置项）。 此岗位可由开发或测试人员兼任。 3.第四章容 4.1. 版本管理对象 包括但不限于： 项目总体计划 可行性研究报告 开发计划 需求说明书 需求设计原型 设计说明书 系统开发变更申请单 系统管理手册 用户操作手册 培训计划 培训记录 源程序 支持系统运行的配置文件 存储过程脚本 测试计划 测试用例 测试脚本 测试报告 上线计划

上线申请 版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目部的目录结构建议按下列格式创建。 配置库目录结构规划： ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中，项目部的目录结构： |–projectA |–src （保存该项目的源程序） |–doc （保存项目相关文档） |–000.项目管理（保存项目过程管理相关文档） |–010.项目计划（保存项目计划相关文档） |–020.项目需求（保存项目需求相关文档） |–030.系统设计（保存项目设计相关文档） |–030.系统测试（保存项目代码测试相关文档） |–040.系统实施（保存项目部署实施相关文档） |–050.系统运维（保存项目运维文档，包括培训、用户手册等） |–060.技术资料（保存项目技术文档，包括第三方技术资料等）

软件配置管理规定

软件配置管理规定? 为进一步加强软件配置管理工作,明确软件配置原则,规范软件配置流程，制定本规定。 一、配置原则? 1、软件配置遵循安全性、适用性、 2、单经济性与正版化得原则，不得配置非正版软件。? 位使用得商业软件、OEM软件、免费软件均需纳入配置管理，不得配置与工作无关得各类软件。?3、优先采用场地授权(许可)方式配置软件。 二、配置流程 1、软件使用部门根据本部门各岗位工作需要，编制岗位软件需求清单，填写《软件使用需求申请表》（附件1)。 ２、信息化部门统计、汇总软件使用部门报送得《软件使用需求申请表》,对软件使用部门需要得相关软件进行统一测试与试用，综合考虑软件得价格、兼容性、安全性与售后服务等因素,确定软件选型,明确软件名称与版本.涉及使用免费软件得,更新《可使用免费软件清单》(附件2）。 3、信息化部门依据单位软件使用管理台账,梳理单位软件需求与现有软件许可得差异。单位软件许可不足得，编制《软件采购计划表》（附件3）。 4、财务部门要将软件采购纳入单位年度预算。财务、资产管理部门指导信息化部门完成软件采购。软件采购合同要明确软件名称、版本、授权方式、许可数量、使用年

限、兼容性与售后服务等要求。?5、财务、资产管理部门指导信息化部门做好软件采购相关资料管理工作，重点就是软件采购合同、软件授权证书、软件安装序列号等资料得管理工作。? 6、信息化部门负责软件使用管理日常工作。?7、单位采购得软件,因以下情况申请报废得，需经过信息化部门鉴定,严格履行资产处置报批手续：?(１）已经达到规定得最低使用年限,且无法继续使用得.?（２）未达到规定得最低使用年限,因技术进步等原因无法继续使用得。?（3）未达到规定得最低使用年限,因计算机硬件报废，且无法迁移到其她计算机上继续使用得. ８、信息化部门在单位新采购软件、报废软件与调整可使用免费软件清单后，更新《软件使用情况汇总表》（附件4)。

软件开发项目配置管理工具的选择

软件开发项目配置管理工具的选择 通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报…… 每一个软件项目，无论是工程类项目，还是产品类项目，都必须经历需求分析、系统设计、编码实现、集成测试、部署、交付、维护和支持的过程。在这个过程中，将生成各种各样不同的工件，包括文档、源程序、可执行代码、支持库。更可怕的是，频繁出现的变更是不可避免的，因此面向如此庞大且不断变动的信息集，如何使其有序、高效地存放、查找和利用就成为了一个突出的问题。 针对这一问题，最早的开发人员尝试过的解决办法是通过手工来实现： 1)文档：每次修改时都另存为一个新的文件，然后通过文件名进行区分，例如"XXX 软件需求说明书V1.0，XXX软件需求说明书V1.1，XXX 软件需求说明书V2.0."，并且在文件中注明每次版本变化的内容； 2) 源代码：每次要修改时就将整个工程目录复制一份，将原来的文件夹进行改名，例如"XX 项目V1.0、XX 项目1.01、."，然后在新的目录中进行修改； 但是这种方法，不仅十分繁琐，容易出错，而且会带来大量的垃圾数据。如果是团队协同开发或者是项目规模较大时，还是会造成很大的混乱。很显然，这样简陋的方法是无法应对这一问题的。后来，有人尝试从制造工业领域引入了"配置管理"这一概念，通过不懈的研究与实践，最终形成了一套管理办法和活动原则，这也就是软件配置管理。 通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报。 常见的配置管理工具 正如前面所述，由于软件配置管理过程十分繁杂，管理对象错综复杂，如果是采用人工的办法不仅费时费力，还容易出错，产生大量的废品。因此，引入一些自动化工具是十分有裨益的，这也是做好配置管理的必要条件。 正是因为如此，市场上出现了大量的自动化配置管理工具，这些工具的实现原理与基本机制

软件配置管理规范流程模板

软件配置管理规范 流程 1 概述 1.1 目的 本文档主要目的在于规范项目配置管理活动, 确保配置项正确地唯一标识而且易于存取, 保证基线配置项的更改受控, 明确基线状态, 在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用范围本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动, 针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法, 本文件以CVS( 并行版本系统) 配置管理工具为例, 规定公司的配置管理办法, 使用其它工具时也可对应本文件

的要求参照执行。 1.3 术语和缩略语 1.3.1 软件配置管理( Software Configuration Management, SCM) 软件配置管理是对软件修改进行标识、组织和控制的技术, 用来协调和控制整个过程。是经过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程, 确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 1.3.2 配置项( Configuration Item, CI) 凡是纳入配置管理范畴的工 作成果统称为配置项, 配置项逻辑上组成软件系统的各组成部分, 一般是能够单独进行设计、实施和测试的。 每个配置项的主要属性有: 名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里, 确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 1.3.3 基线( Baseline) 在配置管理系统中, 基线就是一个配置项或一组配置项在其生命周期的不同时间点上经过正式评审而进入正式受控的一种状态这些配置项构成了一个相对稳定的逻辑实体, 而这个过程被称为基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素( 配置项) 的一个版本, 且只确定一个版本。一般情况下, 基线一般在指定的里程碑处创立, 并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制, 基线中的配置项被冻结”了, 不能再

软件配置管理流程

配置管理流程规定 (Ver1.0) 拟制：___________________ 审核：___________________ 签发：___________________

目录 1.配置管理流程 (3) 1.1概述 (3) 1.2总体流程图 (3) 1.3软件需求分析阶段 (4) 1.4软件设计阶段 (4) 1.5制定配置管理计划 (4) 1.6配置库管理 (4) 1.6.1相关人员分配权限 (4) 1.6.2配置项 (5) 1.7版本控制 (6) 1.8变更控制 (6) 1.9配置审计 (8) 1.9.1配置审核的类别 (8) 1.9.2配置审核执行的时机 (8) 1.9.3不符合项的处理 (8) 2.0.0配置状态报告 (8) 2.0.1配置状态报告的目的 (8) 2.0.2配置状态报告记录的内容 (8) 2.0.3配置状态报告的生成 (9) 2.1.0发行管理 (9) 2.1.1交付管理 (9) 2.软件基线化规范 (10) 2.1正常开发期 (10) 2.2版本发布期 (11) 2.3项目发布期 (13) 3.Jira配置管理 (14)

1.配置管理流程 1.1概述 规范配置管理活动，确保配置项正确地唯一标识并易于存取，保证基准配置项的更改受控，明确基线状态，在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2总体流程图

1.3软件需求分析阶段 参加需求分析会议，配置管理负责人记录，有关文档提交归档。如《需求分析》。 1.4软件设计阶段 参加设计阶段，为了详细制定配置管理计划。针对需求分析报告进行系统设计，配置时应说明系统设计的版本与需求分析报告版本的对应关系。设计书评审通过后，建立设计基线。 1.5制定配置管理计划 配置管理员制定配置管理计划，主要内容包括配置管理软硬件资源、配置项计划、备份计划等，审批该计划。 1.6配置库管理 配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。 1.6.1相关人员分配权限 项目经理： 1)与(有关负责人员)协商确定项目起始基线 2)接受配置管理计划，并按相关规定贯彻执行； 3)接受配置控制委员会的报告。 4)提出配置管理计划的修改要求； 5)提出管理管理的建议和要求。 配置管理员 1)编制配置管理计划； 2)执行配置项管理； 3)执行版本控制和变更控制方案； 4)编制配置状态报告； 5)配置库的建立和权限分配； 6)配置管理工具的日常管理与维护； 7)配置库的日常操作和维护 开发人员

软件三库管理规范

软件三库管理规范-标准化文件发布号：（9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII

1目的范围 规定了公司软件开发库、受控库、产品库（以下简称三库）的管理规范。 2参考文献 《软件三库管理制度》 3术语和定义 GitLab：一个仓库管理系统，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。 Jenkins：基于Java开发的一种持续集成平台，用于监控持续重复的工作。 SPM：公司研发部开发的持续集成工具，用于集成软件部署包。 Releaser：公司研发部开发的基于SPM的软件部署包发布工具。 Kiwi TCMS：公司研发部基于开源代码改进的测试用例管理系统，用于测试计划和测试用例的创建和维护、以及测试执行的记录。 4职责 4.1软件三库管理职责 软件开发库由项目组管理，软件受控库由研发部管理，软件产品库由质量部管理。 4.2软件管理员职责 a)具备软件配置管理知识； b)熟悉研制项目的配置管理； c)熟悉公司结构、软件三库管理规定、标识规定和软件配置管理计划。 5管理内容与方法 5.1建立软件三库 5.1.1 开发库 a)开发库代码部分和说明部分基于GitLab建立，按照软件项目分配仓库。 项目组长任仓库Master，负责需求说明的管理、成员管理、问题跟踪、分支Merge、任务分配、Tag标识等工作。 项目组成员任仓库Developer，负责设计和交付说明的管理、问题调查、分支维护等工作。 测试组成员任仓库Reporter，负责测试说明的管理、报告问题、问题回归等工作。 b)开发库部署包部分基于Jenkins和SPM建立，按照软件项目分配仓库。

软件配置管理规范.doc

软件配置管理规范1 1．简介 软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。 1.1 目的 本文档指导项目开展配置管理活动。 1.2 范围 本文档适用于SWL开发小组批准立项的软件项目。 1.3 文档结构 第一部分： 简介，包括本规范的目的、范围、词汇以及所涉及到的参考信息。 第二部分： 配置管理工作规范的正文，包括活动的流程图、进入能及退出的准则、所涉及的角色、相 关活动的阐述、验证与确认能及度量。 第三部分： 变更控制工作规范的正文，包括活动的流程图、进入能及退

出准则、所涉及的角色、相关 活动的阐述、验证与确认能及度量。 第四部分： 参考文献，列出了编写本规范所参考的相关的文献资料。 第五部分： 附录，本文中流程图的标准符号定义。 1.4 词汇表 CM (Configuration Management) 配置管理。 CCB (Change Control Board) 变更控制委员会。 CI (Configuration Item) 配置项，包含文档、程序。 CR (Change Request) 变更请求，对提出的要变更工件或流程的任何请求的统称。在变更请求中记录的信息 是有关当前问题、提议解决方案及其成本的起源和影响的信息。

PCA (Physical Configuration Audit) 物理审计，在配置管理系统中建成立基线的工件是否为“正确”版本。 FCA (Functional Configuration Audit) 功能审计，核心软件配置项的实际性能是否符合它的需求。 基线(Baseline) 己通过复审和批准的工件发布版，由此构成进一步演进或开发的公认基础，并且只能 通过正式程序，例如变更管理和配置控制才能进行更改。 CML (Configuration Management Library) 配置客理库，存储项目工件的所有版本，即存储项目的定义的配置项。 版本(Version) 某个工件的变体，工件的后期版本一般是在初期版本的基础上进行的扩展。 1.5参考信息 1.5.1 可追溯性 CMU/ SET-93-TR-024 Capability Maturity Model SM for Software, Version 1.1

软件配置管理计划示例

软件配置管理计划示例 作者：赵文锋计划名CADCSC软件配置管理计划 项目名中国控制系统CAD工程化软件系统 项目委托单位 代表签名年月日 项目承办单位 代表签名年月日 1 引言 1．1 目的 本计划的目的在于对所开发的CADCSC软件规定各种必要的配置管理条款，以保证所交付的CADCSC软件能够满足项目委托书中规定的各种原则需求，能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。 软件开发单位在开发本项目所属的各子系统（其中包括为本项目研制或选用的各种支持软件）时，都应该执行本计划中的有关规定，但可以根据各自的情况对本计划作适当的剪裁，以满足特定的配置管理需求。剪裁后的计划必须经总体组批准。 1．2 定义 本计划中用到的一些术语的定义按GB/T 11457 和GB/T 12504。 1．3 参考资料 ◆GB/T 11457 软件工程术语 ◆GB 8566 计算机软件开发规范 ◆GB 8567 计算机软件产品开发文件编制指南 ◆GB/T 12504 计算机软件质量保证计划规范 ◆GB/T 12505 计算机软件配置管理计划规范 ◆CADCSC 软件质量保证计划 2 管理

2．1 机构 在本软件系统整个开发期间，必须成立软件配置管理小组负责配置管理工作。软件配置管理小组属项目总体组领导，由总体组代表、软件工程小组代表、项目的专职配置管理人员、项目的专职质量保证人员以及各个子系统软件配置管理人员等方面的人员组成，由总体组代表任组长。各子系统的软件配置管理人员在业务上受软件配置管理小组领导，在行政上受子系统负责人领导。软件配置管理小组和软件配置管理人员必须检查和督促本计划的实施。各子系统的软件配置管理人员有权直接向软件配置管理小组报告子项目的软件配置管理情况。各子系统的软件配置管理人员应该根据对子项目的具体要求，制订必要的规程和规定，以确保完全遵守本计划规定的所有要求。 2．2 任务 在软件工程化生产的各个阶段中，与本阶段的阶段产品有关的全部信息在软件开发库存放，与前面各个阶段的阶段产品有关的信息则在软件受控库存放。在研制与开发阶段的阶段产品的过程中，开发者和开发小组长有权对本阶段的阶段产品作必要的修改；但是如果开发者或开发小组长认为有必要个性前面有关阶段的阶段产品时，就必须通过项目的配置管理小组办理正规的审批手续。因此，软件开发库属开发这个阶段产品的开发者管理，而软件受控库由项目的配置管理小组管理。软件经过组装与系统测试后，应该送入软件产品库，如欲对其修改，必须经软件配置管理小组研究同意，然后报项目总体组组长批准。关于软件配置要进行修改时的具体审批手续，将在第条中详细规定。 2．3 职责 在软件配置管理小组中，各类人员要互相配合、分工协作，共同担负起整个项目的软件配置管理工作。其中各类人员的分工如下： A．组长是总体组代表，他对有关软件配置管理的各项工作全面负责，特别要对更改建议的审批和评审负责； B．软件工程小组组长负责监督在软件配置管理工作中认真执行软件工程规范； C．项目的专职配置管理人员检查在作配置更改时的质量保证措施； D．各子系统的配置管理人员具体负责实施各自的配置管理工作，并参与各子系统的功能配置检查和物理配置检查；

版本管理制度

版本管理规范(草案) 研发部 2009-2-4

目录 文档类别使用对象....................................................... 错误!未定义书签。1．引言................................................................ 错误!未定义书签。 目的 .................................................................. 错误!未定义书签。 范围 .................................................................. 错误!未定义书签。 术语定义 .............................................................. 错误!未定义书签。 版序控制记录 .......................................................... 错误!未定义书签。 版本更新记录 .......................................................... 错误!未定义书签。2．版本管理............................................................ 错误!未定义书签。 2．1版本标识方法...................................................... 错误!未定义书签。 2．1．1正式版本..................................................... 错误!未定义书签。 2．2目录结构.......................................................... 错误!未定义书签。 2．3文档的存放........................................................ 错误!未定义书签。 当前版本和历史版本的存放 ........................................... 错误!未定义书签。 开发文档的存放 ..................................................... 错误!未定义书签。 源代码的存放 ....................................................... 错误!未定义书签。 SQL语句的存放...................................................... 错误!未定义书签。 发行文档的存放 ...................................................... 错误!未定义书签。 2．4权限控制管理...................................................... 错误!未定义书签。3．更新管理（版本升级） ................................................ 错误!未定义书签。 版本升级原则 ........................................................ 错误!未定义书签。 新版本的发布 ....................................................... 错误!未定义书签。4．备份管理............................................................ 错误!未定义书签。5．用户版本管理........................................................ 错误!未定义书签。6．研发部统一管理阶段性版本............................................. 错误!未定义书签。 阶段性版本的提交到研发部............................................... 错误!未定义书签。 阶段性版本的发布到公司网站上........................................... 错误!未定义书签。 各项目组新版本内部及时备份。........................................... 错误!未定义书签。7．版本工具的使用...................................................... 错误!未定义书签。 研发部采用SVN配置管理工具............................................. 错误!未定义书签。8．各项目组提交文档及源码以及规则....................................... 错误!未定义书签。 各项目组需要提交的文档................................................ 错误!未定义书签。 目前所管理的产品列表................................................... 错误!未定义书签。9．周报管理制度........................................................ 错误!未定义书签。10．风险管理制度....................................................... 错误!未定义书签。

软件配置管理控制程序A0

程序文件 软件配置管理控制程序 文件编号 版木A0 贞数第1贞共6贞 編制部门研发部 生效日期2018年09月05日 修改页 文件编号修改条款修改内容修改人/日期生效日期全文首次发行 分发部门会签 编制审核批准□业务部□研发部□采购部□生产韶□质量部□行政部

软件配置管理控制程序 软件配這皆理贯穿于软件整个生命周期，对规范软件版本、源代码、文件、工具、现成软件等控 制要求，确世配置标识、变更控制、配置状态记录等活动要求。使用配置管理工具保证软件质量使公 司的所有软件开发项目的软件配置管理活动都能按照统一的要求进行。 适用于本公司所有的软件项目，并贯穿于软件生存周期全过程。 3.1项目经理 负责指过配置管理人员: 负责审批配置管理il ?划; 负责执行配置管理il 划。 3. 3质量部 > 负责跟踪配置管理il ?划的实施。 4.1术语泄义 软件配置管理：是标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和变更, 记录并报告配置的状态和变更要求，验证配置项的完整性和正确性。 软件配置项：为配置管理的目的而作为一个单元来看待的硬件/软件成分。 基线：一组拥有唯一标识号的需求、设计、源代码文件以及柑应的可执行代码、构造文卷和用户文档 构成一条基线。基线一经放行，就可以作为从配置管理系统检索源代码文卷（配苣项〉和生成可执行 文卷的工具" 4.2配置管理讣划编制 所有项目在指；4^项目开发计划时，都应有项目经理指定配置管理人员，然后由配置管理人员编写 《配置管理计划》，也可以包含在《软件开发计划中》，配置管理讣划至少应包括的内容: ? 配置管理人员的组成及分工 2. 范围 3. 职责 3.2 配置管理人员 4. 工作程序

软件版本管理规范19726

软件版本管理规范 第一章目的 本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容，使软件项目版本管理流程化并规范化，确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用范围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，本文所述使用的是SVN）进行版本管理。 2.第三章职责 配置库管理员：负责配置库的日常维护和管理；监督开发及测试部门及时提交版本管理对象（即配置项）。 此岗位可由开发或测试人员兼任。 3.第四章内容 4.1. 版本管理对象 包括但不限于： 项目总体计划 可行性研究报告 开发计划 需求说明书

需求设计原型 设计说明书 系统开发变更申请单 系统管理手册 用户操作手册 培训计划 培训记录 源程序 支持系统运行的配置文件 存储过程脚本 测试计划 测试用例 测试脚本 测试报告 上线计划 上线申请 版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目内部的目录结构建议按下列格式创建。

配置库目录结构规划： ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中，项目内部的目录结构： |–projectA

软件配置管理规定

软件配置管理规定 为进一步加强软件配置管理工作，明确软件配置原则，规范软件配置流程，制定本规定。 一、配置原则 1.软件配置遵循安全性、适用性、经济性和正版化的原则，不得配置非正版软件。 2.单位使用的商业软件、OEM软件、免费软件均需纳入配置管理，不得配置与工作无关的各类软件。 3.优先采用场地授权（许可）方式配置软件。 二、配置流程 1.软件使用部门根据本部门各岗位工作需要，编制岗位软件需求清单，填写《软件使用需求申请表》（附件1）。 2.信息化部门统计、汇总软件使用部门报送的《软件使用需求申请表》，对软件使用部门需要的相关软件进行统一测试和试用，综合考虑软件的价格、兼容性、安全性和售后服务等因素，确定软件选型，明确软件名称和版本。涉及使用免费软件的，更新《可使用免费软件清单》（附件2）。 3.信息化部门依据单位软件使用管理台账，梳理单位软件需求与现有软件许可的差异。单位软件许可不足的，编制《软件采购计划表》（附件3）。

4.财务部门要将软件采购纳入单位年度预算。财务、资产管理部门指导信息化部门完成软件采购。软件采购合同要明确软件名称、版本、授权方式、许可数量、使用年限、兼容性和售后服务等要求。 5.财务、资产管理部门指导信息化部门做好软件采购相关资料管理工作，重点是软件采购合同、软件授权证书、软件安装序列号等资料的管理工作。 6.信息化部门负责软件使用管理日常工作。 7.单位采购的软件，因以下情况申请报废的，需经过信息化部门鉴定，严格履行资产处置报批手续：（1）已经达到规定的最低使用年限，且无法继续使用的。 （2）未达到规定的最低使用年限，因技术进步等原因无法继续使用的。 （3）未达到规定的最低使用年限，因计算机硬件报废，且无法迁移到其他计算机上继续使用的。 8.信息化部门在单位新采购软件、报废软件和调整可使用免费软件清单后，更新《软件使用情况汇总表》（附件4）。

软件项目配置管理系统计划清单指导应用清单

中国核电集团 CHINA GUANGDONG NUCLEAR POWER GROUP 记录文件 项目编号 项目名称 CGN-IT-C3-A12-01 软件项目配置管理计划 版本编写审核审定批准生效时间A/0 注：如无受控文件标识（蓝色印章）则为非有效版本，以受控文件规定为准。 此文件属中国核电集团所有，未经许可，不得以任何方式外传。

修改记录页

目录 (一)基本信息 (4) (二)角色与职责 (4) (三)配置管理资源 (5) (四)权限分配 (5) (五)配置项计划 (6) (六)配置库基线 (7) (七)配置库备份计划 (8) (八)配置库状态报告 (8) (九)配置审核 (9) (十)审批意见 (9)

配置管理计划(一)基本信息 项目名称： 项目代号： 立项时间： 预计主要项目阶段有： 配置项目命名规则依据： (二)角色与职责

(三)配置管理资源 本项目使用配置管理工具对各配置项进行存储、版本管理，并提供更新、检索和历史版本的恢复。 提示： （1）配置管理员确定本项目的配置管理软件。例如采用Microsoft公司的TFS或者IBM公司的clearecase。 （2）配置管理员根据所采用的配置管理软件，确定计算机资源（考虑存、外存、CPU等）。 预计建库申请日期： 预计建库日期： 预计工作库需空间： (四)权限分配 项目成员访问配置库的ID及PASSWORD默认设置为与域的设置相同。 若个人要求另行设置的，由项目组配置管理员负责汇总后，提交给高级配置管理员调整设置。

(五)配置项计划 填写上面表格过程中，需要对照成果物列表逐项填写。

软件配置管理规范标准

页眉 软件配置管理规范 1.简介 软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。 1.1 目的 本文档指导项目开展配置管理活动。 1.2 范围 本文档适用于SWL开发小组批准立项的软件项目。 1.3 文档结构 第一部分： 简介，包括本规范的目的、范围、词汇以及所涉及到的参考信息。 第二部分： 配置管理工作规范的正文，包括活动的流程图、进入能及退出的准则、所涉及的角色、相关活动的阐述、验证与确认能及度量。 第三部分： 变更控制工作规范的正文，包括活动的流程图、进入能及退出准则、所涉及的角色、相关活动的阐述、验证与确认能及度量。 第四部分： 参考文献，列出了编写本规范所参考的相关的文献资料。 第五部分： 附录，本文中流程图的标准符号定义。 1.4 词汇表 CM (Configuration Management) 配置管理。 CCB (Change Control Board) 变更控制委员会。 CI (Configuration Item) 配置项，包含文档、程序。 CR (Change Request) 变更请求，对提出的要变更工件或流程的任何请求的统称。在变更请求中记录的信息是有关当前问题、提议解决方案及其成本的起源和影响的信息。 PCA (Physical Configuration Audit) 物理审计，在配置管理系统中建成立基线的工件是否为“正确”版本。 FCA (Functional Configuration Audit) 功能审计，核心软件配置项的实际性能是否符合它的需求。 基线(Baseline)

己通过复审和批准的工件发布版，由此构成进一步演进或开发的公认基础，并且只能通过正式程序，例如变更管理和配置控制才能进行更改。 CML (Configuration Management Library) 配置客理库，存储项目工件的所有版本，即存储项目的定义的配置项。 版本(Version) 页脚 页眉 某个工件的变体，工件的后期版本一般是在初期版本的基础上进行的扩展。 1.5参考信息 1.5.1 可追溯性 CMU/ SET-93-TR-024 Capability Maturity Model SM for Software, Version 1.1 1.5.2 方针 SWL开发组项目开发与管理工作方针 1.5.3 过程/规范 项目计划与控制规范 1.5.4 指南 配置管理计划指南 基线策略指南 配置状态报告编制指南 配置审计工作活动指南 配置管理工具指南 VSS 使用指南 组织管理配置库使用指南 软件开发文档命名约定 1.5.5模板 配置管理计划 配置状态报告 配置审计报告 文档变更请求 1.5.6 检查表 无 1.5.7 培训 《软件配置管理教材》 《软件变更控制管理教材》 《Clear Case 配置管理培训教材》 1.5.7 工具 Clear Case Visual SourceSafe Visual Basic Office 97/2000/XP DreamWeaver PhotoShop

软件配置管理控制程序

配置管理控制程序 历史记录

目录

1.引言 1.1目的 本程序文件定义了本组织的配置管理的过程，目的是规范公司的软件配置管理活动，使公司的所有软件开发项目的软件配置管理活动都能按照统一的要求进行。 1.2 使用范围 本文件适用于公司的所有软件项目。 1.3 名词和缩写 CM(Configuration Management) 配置管理 SCCB (Software Configuration Control Board) 软件配置管理控制委员会 CC (Configuration Controller) 配置管理员 工作产品（Work Products）：项目技术开发和管理工作中产生的有价值的成果，例如源代码、数据和各种文档。 配置项（Configuration Item, CI）：纳入到配置管理范畴作为单个实体对待的工作产品称为配置项[IEEE Std 610.12 - 1990 ]；配置项包括：项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入软件配置管理。 基线（Baseline）：一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。基线一经放行，就可以作为从配置管理系统检索源代码文卷（配置项）和生成可执行文卷的工具。 2角色与职责 2.1软件配置管理组（CM） CM组是项目里的一个小组，根据项目大小，可以由一个人，或者多人组成,小组的成员称为配置管理员(CC),通常由公司的质量保证组安排，加入到项目组，由项目经理领导。

CM组建立并管理配置管理库系统。 CM组负责组织相关部门和人员进行有关CM活动的培训。 项目组的CM组负责在该项目的整个生命周期中进行配置管理活动。 2.2软件配置管理控制委员会(SCCB) SCCB建立在项目级，通常由项目经理、该项目的技术经理、软件开发工程师、资深工程师、测试经理/测试工程师以及CC组成。SCCB在项目策划阶段由项目经理负责筹建。 配置管理控制委员会负责审批软件配置管理计划； 配置管理控制委员会负责审批软件基线的建立； 配置管理控制委员会负责审批对软件基线配置项的变更； 配置管理控制委员会负责审核和批准产品发布。 2.3 SCCB负责人 SCCB负责人通常由项目经理担任，代表SCCB在有关文件上签署意见。 2.4 项目经理 定期或事件驱动地评审或审核CM活动。 2.5 测试组 负责审核《配置管理计划》任务列表中与测试有关的内容 2.6 开发组 负责审核《配置管理计划》任务列表中与开发有关的内容 2.7 QA组 负责审核《配置管理计划》任务列表中与QA有关的内容

软件项目-软件配置管理规范-模板

软件配置管理规范 版本：V1.0

目录 1介绍 (1) 1.1目的 (1) 1.2范围 (1) 2规范概述 (1) 3规范详述 (1) 3.1配置库管理规范 (1) 3.1.1配置库说明： (1) 3.1.2配置库目录结构： (2) 3.1.3配置库权限设置： (4) 3.1.4配置库备份机制： (5) 3.2配置项管理规范： (5) 3.2.1配置项入库： (5) 3.2.2配置项标识： (5) 3.3基线管理规范： (8) 3.3.1基线说明： (8) 3.3.2基线分类： (8) 3.3.3基线命名规则 (9) 3.4其它项配置规则： (9) 3.4.1分支命名规则 (9) 3.4.2Eclipse工作空间命名 (9) 3.4.3版本标签命名规则 (9) 3.5过程简称表： (10) 3.6配置类别简称表: (10)

1 介绍 1.1 目的 本规范目的在于指导配置管理人员如何利用配置库管理所有配置项，从而加强对公司软件产品的控制，保持软件产品在其整个生命周期中的一致性、完整性、可追溯性。 1.2 范围 本规范适用于重要软件产品和软件项目的配置项管理。对于非重要软件或已开发好的软件，可以采用本规范规定的要求的子集。 2 规范概述 本规范应用于软件配置管理过程，主要包括配置库的设置，配置项的标示，基线命名等。 3 规范详述 3.1 配置库管理规范 整个项目开发中，把所有的工作成果存放在四个库中，分别为：开发库、受控库、基线库、产品库，每个库下面对应的分为文档库和代码库两部分。前三个库存放到配置管理工具数据库中，产品库建立在文件服务器\\192……\project目录中，根目录名称为项目编号。 配置管理员根据项目情况（项目规模、人员使用工具习惯等）、开发模式（本地开发、异地分布式开发）、财力等因素，确定配置管理工具软件（如：ClearCase、SVN、VSS等）以及计算机资源（内存、CPU、网络环境）；确定存储库备份环境（备份服务器、备份介质）。 3.1.1 配置库说明： 开发库，包括整个开发过程中处于动态变化过程中的工作成果。 受控库，存放项目计划中定义的需要进行控制工作产品。软件配置管理就是对软件受控库中的各软件项进行管理，因此软件受控库也叫做软件配置管理库。 基线库，存放项目过程的基线配置项。