软件配置管理规范(参考模板)

软件配置管理规范

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

Microsoft SQL Server 2000

1.6 参考网站

1．配置管理规范

2.1 配置管理流程图

2.2 角色

本文档在组织中实施所涉及的角色

2.9 度量

2．变更控制规范3.1 变更控制流程图

3.8 度量

3．参考文献

[BUC93]

Implementing Configuration Management,Hardware,Software and Firmware,Los Almitox,CA:IEEE Computer Science Press,j.Buckley 1993.

[Rational 2001]

Rational Unified Process,Version2001,Rational Software Corporation,2001. [SCM_CRI_2.0]

软件配置管理规范，托普信息集团，2002

附录

附录A —流程框图符号

Parallelograms represent Inputs and Output to

or from a process/procedure.

Rectangles represent individual process/procedure activities

Lines with arrowheads connect symbols to show

the progression or directionof he activities.

Diamonds represent important decision points in

the process/procedure.

Circles represent connectors when a process/procedure flowchart continues on the next page

附录B —文档命名指南

根据软件工程文档命名规则GB8567中的建议，文档命名采用以下规则：文档命名由两部分构成，格式如下：

Project_filename.XXX

其中解释如下：

Project代表项目名称的简写，一般不超过6个安符

Filename.XXX是文件名称

Version代表版本号

例如：

SWL_SCMPlan.doc代表的意义如下：SWL项目组的软件配置计划

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

软件版本管理规 第一章目的 本规详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等容，使软件项目版本管理流程化并规化，确保在系统开发和实施过程中项目的完整性和一致性。 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 概述 1.1 目的 本文档主要目的在于规范项目配置管理活动, 确保配置项正确地唯一标识而且易于存取, 保证基线配置项的更改受控, 明确基线状态, 在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用范围本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动, 针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法, 本文件以CVS( 并行版本系统) 配置管理工具为例, 规定公司的配置管理办法, 使用其它工具时也可对应本文件

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

软件三库管理规范

软件三库管理规范-标准化文件发布号：（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建立，按照软件项目分配仓库。

软件配置管理计划示例

软件配置管理计划示例 作者：赵文锋计划名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．各子系统的配置管理人员具体负责实施各自的配置管理工作，并参与各子系统的功能配置检查和物理配置检查；

软件配置管理规范.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

软件配置管理规范标准

页眉 软件配置管理规范 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

版本管理制度

版本管理规范(草案) 研发部 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．风险管理制度....................................................... 错误!未定义书签。

软件配置管理计划模板

卷号DEPLOY 卷内编号DEPLOY005 密级组内 HD20090917SR005 通用型行政审批服务协同管理平台 配置管理计划 1.2 项目承担部门：java第四组 撰写人（签名）：区允文 完成日期：2010年8月4日 本文档使用部门：■主管领导■项目组 □客户（市场）□维护人员□用户 评审负责人（签名）：江威龙 评审日期：2010/8/4

目录 1.简介4 1.1目的4 1.2范围4 1.3定义、首字母缩写词和缩略语4 1.4参考资料4 1.5概述4 2.项目配置4 2.1组织结构4 2.2职责和接口5 2.3工具、环境和基础设施5 3.配置管理活动6

3.1配置库6 3.1.1配置库架构6 3.1.2权限分配7 3.1.3配置库层次及开发活动说明：8 3.2配置标识9 3.2.1标识方法9 3.2.2项目基线10 3.3配置项11 3.4配置和变更控制11 3.4.1变更请求的处理和审批11 3.4.2变更控制委员会 (CCB)11 3.4.3变更过程中的活动11 3.4.4变更过程中的变更请求状态12 3.4.5保存变更历史记录13 3.4.6变更请求中受影响配置项的变更13 3.5配置状态统计14 3.5.1项目介质存储和发布进程14 3.5.2报告和审计14 4.里程碑15 5.培训和资源15 6.分包商和厂商软件控制15 7.附录15

配置管理计划 1.简介 1.1目的 为了使项目相关的各种资源便于查看，修改，不至于凌乱；为了让各个开发人员方便高效地协同合作；为了项目的版本便于管理，作出此配置管理计划。 1.2范围 项目进行中所得出的所有工件都要遵守此计划，包括文档以及源代码，以及硬件。 1.3定义、首字母缩写词和缩略语 CM：配置管理。 CCB：变更控制委员会。 CI：配置项。包含文档、程序。 Baseline：基线。 CR：变更请求。 PCA：物理审计。 FCA：功能审计。 1.4参考资料 《华南农业大学软件学院实训讲义》 《华南农业大学项目阶段评审工件》 1.5概述 此文档对项目开发过程中的配置方面作出约束，开发以及变更都要按照要求来做。 2.项目配置 2.1组织结构

软件配置管理规范流程

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） 在配置管理系统中，基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，这些配置项构成了一个相对稳定的逻辑实体，而这个过程被称为“基线化”。每一

软件版本管理规范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）。

软件配置管理规范精编WORD版

软件配置管理规范精编 W O R D版 IBM system office room 【A0816H-A0912AAAHH-GX8Q8-GNTHHJ8】

软件配置管理规范 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)

软件配置管理规范(参考模板)

软件配置管理规范 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 目的范围 规定了公司软件开发库、受控库、产品库（以下简称三库）的管理规范。 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建立，按照软件项目分配仓库。

项目组成员负责维护自动测试脚本和版本生成脚本。 Jenkins管理员（计算机）任库管理员，负责自动检查代码编译结果，执行版本生成脚本将通过检查的工程生成待测软件部署包，执行自动测试脚本验证软件部署包，将通过验证的软件部署包打上标识，放入仓库。 另任库管理员，负责出入库管理、配置项管理等工作。 5.1.2 受控库 a)受控库代码部分基于GitLab建立，按照软件项目分配仓库。 软件经理任仓库Master，负责将通过完整测试的开发版本打上Tag标识，在GitLab 上作为独立稳定的分支，该分支不接受更改，有效受控。 b)受控库部署包部分基于Jenkins和SPM建立，按照软件项目分配仓库。 Jenkins管理员（计算机）任库管理员，负责将打上Tag标识的代码版本生成软件部署包，打上同样的Tag标识，放入仓库。 该部分目录及目录下文件一旦生成，不可删除或更改，有效受控。 c)受控库说明部分存在于公司内部的公共服务器。 另任库管理员，负责出入库管理、配置项管理等工作。 d)受控库测试用例部分基于Kiwi TCMS建立，按照软件项目分配仓库。 项目组长具有测试计划审核权限，测试组长具有测试用例编辑和测试用例审核权限，测试组成员具有测试用例编辑权限。 5.1.3 产品库 产品库存在于公司内部公共服务器，按照软件项目分配仓库。 另任库管理员，利用Releaser工具将通过申请的打上Tag的受控版本生成软件产品包，负责各产品的出入库管理、配置项管理等工作。 5.2制定三库管理规定 5.2.1 内容要求 软件三库管理规定： a)入库控制 相关人填写入库申请，负责人审批，库管理员操作或检查入库，详见三库管理要求（第5.4、5.5、5.6节）。 b)访问控制 各仓库设置权限管理，一般来说，给予库管理员写权限，给予相关人读权限，详见三库管理要求（第5.4、5.5、5.6节）。

软件配置管理规范

配置管理规范 文件修改控制

目录 1. 目的 2. 适用范围 3. 术语和缩略语 4. 规范内容 5. 引用文件

1.目的 指导配置管理人员如何建立配置库，并利用配置库管理所有配置项，从而提供配置项的存取和检索功能，有利于配置项的更改控制，保证配置项的完整性和可跟踪性。 2.适用范围 适用于所有软件产品和软件项目的配置项管理。配置管理可采用各种工具及手工办法，本文件以Source safe配置管理工具为例，规定公司的配置管理办法，使用其他工具时也可对应本文件的要求参照执行。 3.术语和缩略语 本文件采用NP601100《配置管理》程序使用的术语和缩略语的定义。 4.规范内容 4.1 配置管理的范围 软件配置可包括以下几方面：项目文档，源代码，执行程序，相关设备及资料等。 1）项目文档主要指：立项建议报告、项目启动计划、可行性分析报告、开发计划、需求分析报告、软件功能规格说明书、系统设计报告、数据库表结构、 技术报告、总结报告、验收报告以及上述文档的评审记录。 2）相关设备主要指项目开发和运行环境（包括硬件和软件），以及项目开发和测试过程中使用的专用仪器设备，如读卡机、扫描仪等。 3）相关资料主要指客户提供的行业法规，标准及其调研期间提供的业务单据，往来会议记要，传真，电子邮件，重要的电话记录等。 4.2 各配置项的获得 项目立项之后，软件配置管理负责人SCML即可建立项目配置库，并着手收集各配置项。 1）项目文档。开发各阶段结束时，软件配置管理负责人SCML可向开发人员索要相关文档及对应评审记录，归到配置库。 2）开发人员在出差前应带好与客户会谈的准备材料。根据出差的任务不同，还应准备客满意度调查表，交付书，验收报告等。返回之前应和客户确认，并 在出差回来时交给软件配置管理负责人SCML一份备份，如有客户提供的文

软件配置管理计划

软件配置管理计划示例 计划名国势通多媒体网络传输加速系统软件配置管理计划 项目名国势通多媒体网络传输加速系统软件 项目委托单位代表签名年月日 项目承办单位北京麦秸创想科技有限责任公司 代表签名年月日 1 引言 1．1 目的 本计划的目的在于对所开发的国势通多媒体网络传输加速系统软件规定各种必要的配置管理条款，以保证所交付的国势通多媒体网络传输加速系统软件能够满足项目委托书中规定的各种原则需求，能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。 软件开发单位在开发本项目所属的各子系统（其中包括为本项目研制或选用的各种支持软件）时，都应该执行本计划中的有关规定，但可以根据各自的情况对本计划作适当的剪裁，以满足特定的配置管理需求。剪裁后的计划必须经总体组批准。 1．2 定义 本计划中用到的一些术语的定义按GB/T 11457 和GB/T 12504。 1．3 参考资料

◆GB/T 11457 软件工程术语 ◆GB 8566 计算机软件开发规范 ◆GB 8567 计算机软件产品开发文件编制指南 ◆GB/T 12504 计算机软件质量保证计划规范 ◆GB/T 12505 计算机软件配置管理计划规范 ◆国势通多媒体网络传输加速系统软件质量保证计划 2 管理 2．1 机构 在本软件系统整个开发期间，必须成立软件配置管理小组负责配置管理工作。软件配置管理小组属项目总体组领导，由总体组代表、软件工程小组代表、项目的专职配置管理人员、项目的专职质量保证人员以及各个子系统软件配置管理人员等方面的人员组成，由总体组代表任组长。各子系统的软件配置管理人员在业务上受软件配置管理小组领导，在行政上受子系统负责人领导。软件配置管理小组和软件配置管理人员必须检查和督促本计划的实施。各子系统的软件配置管理人员有权直接向软件配置管理小组报告子项目的软件配置管理情况。各子系统的软件配置管理人员应该根据对子项目的具体要求，制订必要的规程和规定，以确保完全遵守本计划规定的所有要求。 2．2 任务

配置管理规范文件精选

配置管理规范

配置管理规范模板 目录 1. 目的 2. 适用范围 3. 术语和缩略语 4. 规范内容 5. 引用文件 1. 目的 指导配置管理人员如何建立配置库，并利用配置库管理所有配置项，从而提供配置项的存取和检索功能，有利于配置项的更改控制，保证配置项的完整性和可跟踪性。 2. 适用范围 适用于所有软件产品和软件项目的配置项管理。配置管理可采用各种工具及手工办法，本文件以Source safe配置管理工具为例，规定公司的配置管理办法，使用其他工具时也可对应本文件的要求参照执行。 3. 术语和缩略语 本文件采用NP601100《配置管理》程序使用的术语和缩略语的定义。 4. 规范内容 4.1 配置管理的范围 软件配置可包括以下几方面：项目文档，源代码，执行程序，相关设备及资料等。 1）项目文档主要指：立项建议报告、项目启动计划、可行性分析报告、开发计划、需求分析报告、软件功能规格说明书、系统设计报告、数据库表结构、技术报告、总结报告、验收报告以及上述文档的评审记录。 2）相关设备主要指项目开发和运行环境（包括硬件和软件），以及项目开发和测试过程中使用的专用仪器设备，如读卡机、扫描仪等。 3）相关资料主要指客户提供的行业法规，标准及其调研期间提供的业务单据，往来会议记要，传真，电子邮件，重要的电话记录等。 4.2 各配置项的获得 项目立项之后，软件配置管理负责人SCML即可建立项目配置库，并着手收集各配置项。1）项目文档。开发各阶段结束时，软件配置管理负责人SCML可向开发人员索要相关文档及对应评审记录，归到配置库。 2）开发人员在出差前应带好与客户会谈的准备材料。根据出差的任务不同，还应准备客满意度调查表，交付书，验收报告等。返回之前应和客户确认，并在出差回来时交给软件配置管理负责人SCML一份备份，如有客户提供的文献资料、有关设备仪器须进行登记。对于任何正在进行的项目，如有客户来访须做好会议纪要。 3）开发部门发给客户的传真件或客户发来传真至少应在项目档案中保存一份备份。 4）对于源代码和执行程序的管理最好使用工具，条件不具备时，要注意对配置库的目录分配。各开发人员分别建立自己的工作目录，完成后的模块再放到项目相关目录下。 5）在项目结束归档时电子邮件也应作为项目的相关资料进行归档。 4.3 配置库的建立 所有项目应建立一配置库，以便管理前面提到的各配置项。一般的可视化开发环境都有自带的配置管理工具，可以用管理工具来建立配置库，也可以在机器的某目录下建立配置库，手工管理。下面以Source Safe为例描述配置管理库的建立及各配置项的控制方法。各项目在开始时，均应建立以下几项子项目，进行分阶段管理。