下载文档原格式
软件配置管理文档范本一、引言软件配置管理（Software Configuration Management, SCM）是指对软件产品的开发、测试、交付和维护过程中的各种配置项进行有效的控制和管理，以确保软件开发过程的可控性和可追溯性。
本文档旨在提供一个软件配置管理的范本，帮助项目团队进行规范的配置管理工作。
二、配置管理计划1. 引言配置管理计划（Configuration Management Plan, CMP）是指对整个软件开发项目进行配置管理的计划，包括配置管理活动的安排、配置项的标识和控制、变更管理等内容。
2. 配置管理活动安排(1) 配置库的建立和维护配置库是存储和管理软件开发项目各个版本、各个配置项的地方。
配置库的建立和维护需要确定合适的存储方式和清晰的分类规则，以便于对各个配置项进行有效的管理。
(2) 配置项标识和控制配置项标识是对每个配置项进行唯一标识，以便于在开发、测试、交付和维护过程中进行溯源和变更管理。
配置项控制是对各个配置项进行版本控制和变更控制，确保软件开发过程的可控性。
3. 变更管理(1) 变更控制流程变更控制流程包括变更请求的提出、变更评估和变更实施等环节，确保变更能够按照既定的流程进行评审和实施，避免对软件开发过程造成不可预知的影响。
(2) 变更记录变更记录是对变更过程中的各个环节进行记录和追踪，包括变更请求的来源、变更评估结果、变更实施情况等内容。
变更记录的建立可以为软件开发过程的分析和评估提供参考依据。
三、配置管理工具配置管理工具是指用于辅助配置管理活动的软件工具，可以提高配置管理工作的效率和准确性。
常见的配置管理工具包括版本控制工具、配置项跟踪工具、变更管理工具等。
1. 版本控制工具版本控制工具用于对软件开发过程中的各个版本进行管理，可以进行代码版本的比较、合并和回滚等操作，确保在多人协同开发环境中的代码一致性和可追溯性。
2. 配置项跟踪工具配置项跟踪工具用于对软件开发过程中的各个配置项进行跟踪和溯源，可以追踪某个配置项的修改历史和关联关系，方便进行变更管理和问题定位。
文件编号：PTS - PDP - SCMP软件配置管理计划拟制：____________________ 日期：____________________ 审核：____________________ 日期：____________________ 批准：____________________ 日期：____________________太平洋软件（中国）有限公司变更记录页单位：太平洋软件（中国）有限公司，以下简称PTS文档名称：软件配置管理计划生成日期：2002-12-13版本作者日期备注目录1介绍 (1)1.1 目的 (1)1.2 范围 (1)1.3 缩写和定义 (1)2SCM管理 (2)2.1 组织 (2)2.2 SCM责任 (2)2.3 可用的策略、指令和程序 (2)3SCM 活动 (3)3.1 配置标识 (3)3.1.1 配置项的标识 (3)3.1.2 配置项的命名 (3)3.1.3 配置项的获取 (3)3.2 配置控制 (4)3.2.1 请求变更 (4)3.2.2 评估变更 (4)3.2.3 批准或拒绝变更 (5)3.2.4 实施变更 (5)3.3 配置状态统计 (5)3.4 配置审核和审计 (6)3.5 接口控制 (6)3.6 转包商/供应商控制 (6)4进度安排 (8)5SCM 资源 (8)6SCM计划维护 (8)软件配置管理计划1介绍1.1目的1.2范围1.3缩写和定义2SCM管理SCM管理信息描述了组织和个人在项目的SCM活动中的责任和权限。
SCM管理信息必须包括三个主题：应用SCM的项目组织，这些组织的SCM责任，以及应用在这个项目中的SCM政策和指令。
2.1组织组织结构包括技术和管理两方面，计划中的并将要被实施的SCM活动必须被描述。
计划必须说明以下问题：a)在项目中，参与或对任何SCM活动负责的组织单位；b)在项目结构中，组织单位的功能角色；c)各组织单位之间的关系。
卷号DEPLOY卷内编号DEPLOY005密级组内HD20090917SR005通用型行政审批服务协同管理平台配置管理计划1.2项目承担部门：java第四组撰写人（签名）：区允文完成日期：2010年8月4日本文档使用部门：■主管领导■项目组□客户（市场）□维护人员□用户评审负责人（签名）：江威龙评审日期：2010/8/4目录1.简介41.1目的41.2范围41.3定义、首字母缩写词和缩略语41.4参考资料41.5概述42.项目配置42.1组织结构42.2职责和接口52.3工具、环境和基础设施53.配置管理活动63.1配置库63.1.1配置库架构63.1.2权限分配73.1.3配置库层次及开发活动说明：83.2配置标识93.2.1标识方法93.2.2项目基线103.3配置项113.4配置和变更控制113.4.1变更请求的处理和审批113.4.2变更控制委员会 (CCB)113.4.3变更过程中的活动113.4.4变更过程中的变更请求状态123.4.5保存变更历史记录133.4.6变更请求中受影响配置项的变更133.5配置状态统计143.5.1项目介质存储和发布进程143.5.2报告和审计144.里程碑155.培训和资源156.分包商和厂商软件控制157.附录15配置管理计划1.简介1.1目的为了使项目相关的各种资源便于查看，修改，不至于凌乱；为了让各个开发人员方便高效地协同合作；为了项目的版本便于管理，作出此配置管理计划。
1.2范围项目进行中所得出的所有工件都要遵守此计划，包括文档以及源代码，以及硬件。
1.3定义、首字母缩写词和缩略语CM：配置管理。
CCB：变更控制委员会。
CI：配置项。
包含文档、程序。
Baseline：基线。
CR：变更请求。
PCA：物理审计。
FCA：功能审计。
1.4参考资料《华南农业大学软件学院实训讲义》《华南农业大学项目阶段评审工件》1.5概述此文档对项目开发过程中的配置方面作出约束，开发以及变更都要按照要求来做。
XXXX总线采集设备软件配置管理计划共10 页型别：XXXX有限责任公司技术文件专用纸目录1 范围 (1)1.1 标识 (1)1.2 系统概述 (1)1.3 文档概述 (1)1.4 与其它计划的关系 (1)2 引用文档 (1)3 组织和职责 (2)3.1 配置管理（CM） (2)3.1.1 职责 (2)3.1.2 组织人员名单 (2)3.2 配置管理委员会（CCB） (2)3.2.1 职责 (2)3.2.2 组织人员名单 (2)4 软件配置管理活动 (3)4.1 配置标识 (3)4.1.1 项目开发工具 (3)4.1.2 识别配置项和基线 (4)4.2 配置控制 (5)4.2.1 配置库的管理 (5)4.2.2 基线发布控制 (5)4.2.3 变更控制 (5)4.3 配置状态纪实 (6)4.3.1 配置状态记录 (6)4.3.2 配置状态报告 (7)4.4 配置审核 (7)4.5 软件发行管理和交付 (8)5 工具、技术和方法 (8)5.1 配置服务器 (8)5.2 配置管理工具 (8)5.3 培训 (8)6 对供货单位的控制 (9)7 进度表 (9)8 注释 (9)1范围1.1标识本文档适用于型号为HMS322100JM22-JP XXXX总线采集设备，XXXX总线采集设备的软件包括：地面采集设备软件和随机（机载）采集设备软件。
文件标识号：HMS322100JM22-JP – PJ。
1.2系统概述XXXX总线采集设备是为XXXX交付的产品，适用于XXXX总线采集与分析研究，主要完成总线通讯、通信原始数据及指定接口的通信原理和通信协议分析。
1.3文档概述本计划适用于XXXX总线采集设备的软件配置管理工作。
作为配置管理活动的依据，本文档的内容包括：a)定义组织和职责；b)识别和标识配置项，定义控制级别；c)识别基线；d)明确配置控制的要求、状态报告的要求、配置审计的要求；e)配置管理活动的计划安排。
XXXX软件项目配置管理计划XXXX企业有限公司____年___月___日文档信息修改记录目录软件项目配置管理计划 (2)1 引言 (2)1.1 编写目的 (2)1.2 术语定义 (2)1.3 参考资料 (2)2 计划内容 (2)2.1 人员及职责 (2)2.2 软硬件环境计划 (4)2.2.1 项目计划环境 (4)2.2.2 需求分析和设计环境 (4)2.2.3 开发环境 (4)2.2.4 测试环境 (4)2.2.5 配置管理环境 (4)2.3 配置项计划 (4)2.4 配置库计划 (6)2.5 权限计划 (7)2.6 基线计划 (8)2.7 发布计划 (8)2.8 配置库备份计划 (9)软件项目配置管理计划1 引言1.1 编写目的本文档目的在于对本公司项目进行软件配置管理，提高软件质量，降低软件开发成本。
本计划制定了本公司如何进行配置管理活动、活动的计划安排、指派的职责和所要求的资源。
对本公司项目实施软件配置管理活动时，需要参照本计划。
1.2 术语定义1、软件配置管理（SCM）：软件配置管理是一门应用技术、管理和监督相结合的学科，通过标识和文档来记录配置项的功能和物理特性，控制这些特性的变更，记录和报告变更的过程和状态，并验证它们与需求是否一致。
2、配置项（CI）：配置项可包括以下几方面：项目(或活动)文档、源代码、可执行代码、度量数据、变更请求(CR)。
项目(或活动)文档即项目(或活动)相关的规范、指南中定义的各个任务的输出和输入；源代码和可执行代码是特殊的文档；度量数据指度量分析定义表中定义的度量以及对应的实际数据。
3、基线（BaseLine）: 用来标识一组配置项的特定版本的集合的标记，以记录工作成果的历史状态，或通过不同的版本组合定义不同特性的工作成果。
1.3 参考资料2 计划内容2.1 人员及职责1、根据《软件项目计划书》中的角色分配，确定CM，CCB（变更控制委员会）成员；2.2 软硬件环境计划2.2.1 项目计划环境软件：MS Office Word、MS Office Excel、MS Office Project2.2.2 需求分析和设计环境软件：MS Office Word、MS Office Visio、Sybase PowerDesigner、Rational Rose2.2.3 开发环境软件：Windows Visual Studio .Net、MyEclipse、JDK、Apache-Tomcat、Apache、Oracle 10g、SQL Server 2003、WebLogic、SQL Server 2005、Websphere2.2.4 测试环境软件：Load Runner2.2.5 配置管理环境1、软件：TortoiseSVN2.3 配置项计划配置管理员标识配置项，标识符的参考格式为：项目编号-配置项类型-配置项序号-配置项版本配置项名称。
实用标准文案精彩文档机电管理系统性能测试系统配置管理计划文档编号：XXXXXXXX-XXX-XXX版本号：1.00产品名称:机电管理系统性能测试系统文档名称:配置管理计划版本修改内容描述修改人日期备注1.00 第一版1.01 修正了几个不足1.02 增加对受控文件修改后必须增加描述内容批准人：日期：审核人：日期：这里填写公司地址、联系方式等目录1. 引言 (1)1.1 目的 (1)1.2 术语定义 (1)1.3 参考资料 (2)2. 软件配置 (3)2.1 软件配置环境 (3)2.2 软件配置项 (3)2.3 配置管理员 (4)3. 软件配置管理计划 (6)3.1 建立示例配置库 (6)3.2 配置标识管理 (8)3.3 配置库控制 (10)3.4 配置的检查和评审 (12)3.5 配置库的备份 (14)3.6 配置管理计划的修订 (14)3.7 配置管理计划附属文档 (15)4. 里程碑 (17)附录1 文档命名规定 (19)1、受控配置库文件命名规则 (19)2、非受控配置库文件命名规则 (20)3、提交文档文件命名规则 (20)附录2 文档编码规范 (21)附录3 帐号及权限管理 (23)附录4 配置库使用规定 (26)文档修改记录 (28)1. 引言1.1 目的本文档目的在于机电管理系统性能测试系统进行软件配置管理，提高软件质量，降低软件开发成本。
本文档内容主要参考研发中心相关的ISO程序和制度文档，并在这基础上整理成适合本项目的软件配置管理，为项目经理、配置管理员及相关人员提供日常的配置管理操作步骤。
1.2 术语定义软件配置管理：简称SCM（Software Configuration Management的缩写），是在项目开发中，标识、控制和管理软件变更的一种管理。
配置管理的使用取决于项目规模和复杂性以及风险水平。
软件的规模越大，配置管理就显得越重要。
基线：(BaseLine) 是项目储存库中每个工件版本在特定时期的一个“快照”。
可编辑修改精选全文完整版软件配置管理规范编制XXXXX审核XXXXX批准XXXXX发布日期软件配置管理规范更改更改人单号/日期——XX/2022- 10-29 更改后的版次A/00更改序号1 第一次发布更改说明软件配置管理规范本文件用于规范软件的配置管理过程。
本程序合用于本公司开辟的XX 软件，其他软件组件可参考实施。
无在整个软件生命周期内，管理软件配置项的版本变更及发布。
配置项包括：源代码文件、配置文件、数据库脚本、资源文件、构建安装相关的脚本与说明文档、生成的二进制可执行文件、引用的库文件、安装文件、设计文档、设计评审记录、设计验证记录、现成软件。
还包括开辟管理、质量管理、风险管理等与软件开辟相关的文档。
使用Apache Subversion 作为版本控制工具。
使用FTP 管理现成软件与安装文件。
建议的SVN 目录如下，可以根据实际情况做变动。
trunk trunk 目录为开辟目录，即最新的内容doc 存放设计相关的文档：输入输出文档，设计相关的记录及验证文档软件配置管理规范buildsrc3rd_partyXX-libsincludelibpublictemplateunittest[project][module]toolsexportexamplestesting[version]branches[branch]tags[tag]documentsmain存放构建与安装相关的脚本文件，说明文档，软件配置表源代码目录开源的第三方内容lib 如果第三方库有静态库，统一放在这里，便于引用... 每一个第三方库单独放在一个子目录公司自己的公共库lib 如果公共库有静态库，统一放在这里... 每一个公共库单独放在一个目录引用的头文件，除XXX 和XXX 的内容，包括但不限于：整个项目相关的定义头文件、配置头文件，接口文件；其他硬件产品的引用头文件；其他工程的引用头文件，定义头文件，其他工程可以是本仓库内的工程；... 按内容，头文件可以再分目录存放与include 对应，引用的静态库，除3rd_party 和XX-libs 的内容，包括但不限于：其他硬件产品的引用静态库；其他工程的引用静态库，其他工程可以是本仓库内的工程；多个工程共用的源码文件模板，配置文件的模板、数据文件的模板、数据库创建脚本等单元测试代码目录工程目录，每一个工程单独一个目录模块目录，每一个模块单独一个目录编写的工具工程或者脚本，不发布可以供其他工程(不在本仓库)使用的输出文件，包括头文件、动态库文件、静态库文件示例工程目录，以下可以再分目录存放测试分支的目录发布前的测试分支，来源于trunk 的拷贝，每一个版本单独一个目录存放试验性分支试验性质的分支，来源于trunk 的拷贝，每一个分支单独一个目录存放分布的标签发布的标签，来源于每一个测试分支的最后一个测试修订其他文档：计划文档，软件测试文档，软件更改相关文档使用external 属性设定，引用/trunk/doc开辟期所有的变更提交至/trunk 目录。
1概述目的本文档主要目的在于规范项目配置管理活动,确保配置项正确地唯一标识并且易于存取,保证基线配置项的更改受控,明确基线状态,在整个软件生命周期中建立和维护项目产品的完整性和可追溯性;适用范围本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动,针对项目不同在流程上作适当的删减;配置管理可采用各种工具及手工办法,本文件以CVS并行版本系统配置管理工具为例,规定公司的配置管理办法,使用其他工具时也可对应本文件的要求参照执行;术语和缩略语软件配置管理Software Configuration Management,SCM软件配置管理是对软件修改进行标识、组织和控制的技术,用来协调和控制整个过程;是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施;配置管理的目标是记录软件产品的演化过程,确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置;配置项Configuration Item,CI凡是纳入配置管理范畴的工作成果统称为配置项,配置项逻辑上组成软件系统的各组成部分,一般是可以单独进行设计、实施和测试的;每个配置项的主要属性有：名称、标签、文件状态、版本、作者、日期等;所有配置项都被保存在配置库里,确保不会混淆、丢失;配置项及其历史记录反映了软件的演化过程;基线Baseline在配置管理系统中,基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态,这些配置项构成了一个相对稳定的逻辑实体,而这个过程被称为“基线化”;每一个基线都是其下一步开发的出发点和参考点;基线确定了元素配置项的一个版本,且只确定一个版本;一般情况下,基线一般在指定的里程碑处创建,并与项目中的里程碑保持同步;每个基线都将接受配置管理的严格控制,基线中的配置项被“冻结”了,不能再被任何人随意修改,对其修改要严格地按照变更控制的过程进行;在一个软件开发阶段结束时,上一个基线加上增加和修改的基线内容形成下一个基线;基线的主要属性有：名称、标签、版本、日期等;权限与职责研发总经理助理1 审核变更请求;项目经理Project Manager,PM1 审核批准配置管理计划；2 接收或拒绝小范围的变更申请；3 召集评估变更；4 提出配置管理的建议和要求；5 配合配置管理员的工作;配置管理员Configuration Management Officer,CMO1 编写配置管理计划；2 执行版本控制和变更控制方案；3 制定访问控制策略；4 负责项目的配置管理工作,包括搭建环境、权限分配、配置库的建立、配置项的控制等；5 配置管理工具的日常管理与维护；6 配置库的日常操作和维护；7 负责配置审核并提交报告；8 根据配置部署表单编译发布版本,并维护版本；9 对开发人员进行相关的培训；10 对配置审核中发现的不符合项,拟订纠正措施,要求相关责任人进行纠正;11 监督项目组成员规范的执行情况;开发人员Developer1 根据确定的配置管理计划和相关规定,提交配置项和基线；2 负责项目组内部测试；3 负责软件集成和版本生成；4 按照软件配置管理工具的使用模型来完成开发任务;2 实施细则配置项管理配置项的范围软件配置可包括以下几方面：开发文档,代码,第三方控件、插件,参考资料,测试文档,用户文档,项目管理文档,验收文档等;l 项目文档主要指：立项建议书、可行性分析报告、技术建议书、用户需求说明书、项目计划、项目进度计划、项目阶段性计划、产品需求规格说明书、概要设计报告、详细设计、数据库设计、界面设计、用户操作手册、用户安装手册、培训文档、验收报告以及上述文档的评审记录;l 代码主要指：源代码等;l 工具主要指：脚本文件、插件、第三方控件等;配置项基线管理结合SPP和ISO9000的相关规定,配置管理员根据配置管理规范及配置管理计划,对配置项进行分阶段管理,每一阶段正式评审通过后纳入受控库,作为该项目的一个基线;l 项目启动：配置项包括技术建议书、可行性分析报告、用户需求说明书等立项阶段产生的文档,评审或审批通过后建立发布基线;l 需求阶段：系统调研后开发人员进行需求分析,并整理产品需求规格说明书;产品需求规格说明书经过客户的确认后,建立需求基线;如需升级版本则必须通过评审或审批并得到客户的确认;l 项目计划：需求分析完成后即可制定项目的开发计划,包括项目计划和主要下属计划;包括项目进度计划、配置管理计划、质量保证计划、测试计划、项目阶段性计划;项目开发计划评审通过后,建立项目计划基线;l 设计：系统设计可分为概要设计、详细设计、数据库设计、数据库字典、界面设计;针对用户需求规格说明书进行系统设计,配置时应说明系统设计的版本与需求分析报告版本的对应关系;设计说明书评审或审批通过后,建立设计基线;l 编码设计实现：编码按功能模块分子项目,即每个模块记作一个配置项;代码在提交项目组系统测试时建立Beta版本,系统测试产品正式发布后建立Version版本;l 测试：单元测试和系统测试;单元测试通过提交单元测试报告,项目启动后应提交系统测试计划,系统测试完成后应提交系统测试报告;配置时应说明测试的版本与编码版本的对应关系;系统测试完成后建立测试基线;l 版本发布：项目组提交部署表单,CMO根据部署表单进行编译,发布测试服务器上,并对版本进行维护;同时将发布的版本上传到文档服务器上备份;l 交付与验收：在交付前配置审核完成后建立产品基线,产品基线包含程序以及有关文档配置项,包括交付文档、代码、工具等;l 产品部署：部署时应包括操作手册、安装维护手册、维护文档以及必要的业务和技术培训文档;l 相关资料：相关资料也应作为配置项纳入配置管理,此部分包括：1 相关法律、法规；必须遵照或项目组约定的技术规范；2 与客户或项目组内部重要的交互信息记录,如会议记录、会谈记录、e-mail和MSN 记录等；版本控制文档的版本控制所有文档的管理纳入配置管理库,用版本控制工具进行统一管理;文档的版本控制主要通过文档的名称、文档控制页及版本控制工具的标签来实现,主要分为以下几类：版本变化型文档命名方式：文档名称+子系统名称可选适用文档：项目计划、配置管理计划、质量保证计划、项目进度计划、用户需求规格说明书、产品需求规格说明书、体系结构设计报告、数据库设计报告、详细设计报告、用户操作维护手册、测试用例等;示例：项目计划.doc详细设计_SP门户.doc标签结构：大版本+ 子系统简称+ 版本号+ 日期标签控制说明版本信息l 大版本：可选,表示同一项目为不同用户定制的版本;l 子系统简称：可选,当一个项目有多个子系统时,为区分不同子系统而设置;l 版本号：采用Vs_x_y的形式;l 日期：纳入基线管理的日期,用8位表示,如说明：a. 文档发布名称采用文档名+ Vs_x_y的形式,文档的版本号应该和版本控制工具中相应标签上的版本号一致;b. 对文档的修改需要从配置管理库中取到本地进行;c. 对于文档小的修改,如文字错误,格式调整,变更Vs_x_y中的y来区别如：V1_0_1;d. 文档内容没有大的增加和删节,意思表述没有发生重大的变化,版本标识通过版本工具中加上x标签来表示如：V1_1_0,以及在文档内部控制页标注变化来表示;e. 文档有重大增加和删节,意思表述有重大变化的,版本标识通过在相应文档加上s 标签来表示如：V2_0_0;f. 对于纳入基线库的文档的修改需要提交变更申请,经批准才能进行修改,并且修改的内容要经再次评审才能重新纳入基线库,作为后续阶段的参考文档;时间区别型文档命名方式：文档名称＋撰写时间适用文档：文档名称有明确的含义,需要用时间标识的日常性文档;如周例会会议纪要,项目月计划,项目月总结,阶段性计划等等;示例：周例会会议纪要时间序号型文档命名方式：文档名称+人员姓名拼音+撰写时间+序列号适用文档：测试报告示例：单元测试报告其他文档：对于不能按照前四种类型进行命名的文档会议纪要：会议纪要YYYYMMDD示例：9月9日召开的项目启动会命名为：会议纪要项目启动.doc评审报告：评审报告YYYYMMDD同”会议纪要”要求一致;示例：10月9日召开的项目总体方案评审命名为：评审报告总体方案.doc发行版本表示发行版本采用标签说明,结构如下：大版本+ 版本类型+ 版本号+ 子系统简称拼音+日期+序号大版本：可选,表示同一项目为不同用户定制的版本;子系统简称：可选,当一个项目有多个子系统时,为区分不同子系统而设置;版本类型：分为3种Beta表示项目组内部测试,标签：Release系统测试,标签：Version正式发行版,标签：版本号对于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… 表示在主线上的标签;配置库管理配置库的分类配置库统一由配置管理员负责管理,服务器端使用,客户端主要使用乌龟CVS;配置库目录结构如下：配置库的建立所有项目应建立配置库,以便管理各配置项,配置管理员组织建立配置库;程序库主要通过设置版本的分支来实现对配置项权限管理：1开发库：开发人员相对比较自由的存储空间,开发人员可以在自己的权限范围内任意取出提交;2基线库：配置管理员有最高权限,其余相关人员均为读的权限,发生变更时变更人员须提交变更申请后方可修改基线库内的配置项;文档评审通过后,文档严格受控;由配置管理员将通过评审后的文档移植到基线库里同时将该配置项从开发库移除;代码一般在移交系统测试时纳入基线库受控,可根据项目的具体情况设置基线;3产品库：产品库的产品均出自于基线库,产品库存储的产品用于交付和存档;配置三库统一由配置管理员管理,根据各开发阶段的实际情况定制相应的版本选取规则,来保证开发活动的正常运作;在变更发生时,应及时做好基线的推进;分配权限项目开始后配置管理员编写配置库目录结构表明确项目组成员以及相关人员的权限;在wincvs里有三种权限,读r、写w、添加删除c权限;在开发库内,文档部分项目组成员有rcw权限,其他相关人员只r权限；代码部分项目组成员有rcw权限,其他相关人员没有任何权限;在基线库内,项目组成员仅有r权限,其他相关人的权限视情况而定;在产品库内,所有人没有任何权限;配置管理员在三库内均拥有最高权限;配置变更控制变更的分类软件及其相关文档的变更按照变更的影响范围进行分类：1A级：变更会影响系统级的需求、外部接口、产品价格或者交付期；这类变更必须经过配置管理委员会审核并有客户批准和确认;2B级：变更会影响配置项间的功能接口、内部功能的设计、组件；这类变更必须由项目经理或配置管理委员会的批准和认可;3 C级：变更只会影响配置项内部或对BUG问题的处理；这类变更可以由配置项的管理人员负责批准;系统测试前变更控制流程：系统测试完毕发布release版本后变更控制流程图2 变更控制流程变更请求的提出a．由技术支撑中心汇集顾客意见,影响到需求变更则填写配置项变更控制报告,并提交给配置管理员;b．配置管理员对申请表是否清晰、明确和完整性进行审查,若发现变更不明确或不完整,应返回申请者;对通过审查的变更申请分配变更ID,以便跟踪和记录变更信息;评估变更a．配置管理员将配置项变更控制报告发送给项目经理或者其他授权人员,由项目经理负责对变更进行评估;b．项目经理对变更进行分解,一般的BUG修正不需要审批直接由项目经理决定是否需要变更;新增功能或对整个项目影响重大的变更必须由研发总助审批通过后方可变更;变更评估文档在完成变更评估后发送给配置管理员;变更实施和确认a．变更被批准后,项目经理提交变更实施进度计划,开发人员开始实施变更,并详细记录变更的内容；质量部对变更的实施进行跟踪;b．对于代码变更,必须进行回归测试,以确保变更没有引入新的Bug;另外与变更相关的文档必须修订,以反映变更;当变更以及测试完成后,进行提交;c．通过测试后,质保人员需对变更进行审核,审核的范围一般涉及以下方面：测试记录；变更请求；配置项的检入及检出；文件的命名；版本的编号;a．审核后,由配置管理员更新到基线库中;配置状态报告目的记录和报告整个软件生命周期演化状态;记录内容配置状态报告记录的内容包括：1 软件和文档的标识；2 目前状态；3 基线演化状态；4 变更状态；5 版本交付信息等;生成报告配置管理报告自第一个基线创建时建立,由配置管理系统生成,及时反映当前配置状态;配置审核类别配置审核分为：1功能配置审核Functional Configuration Audit,FCA：审核软件功能是否与需求一致,并符合基线文档要求,通常要审查测试文档等;2 物理配置审核Physical Configuration Audit,PCA：审核要交付的组成项是否存在,是否包含所有必需的项目,如正确版本的源代码、资源、文档、安装说明等等;执行时机通常选择以下几种情况由质量保证人员负责实施配置审核：1软件产品交付或是软件产品正式发行前；2软件开发的阶段工作结束后；3在产品维护工作中,定期地进行;不符合项处理对配置审核中发现的不符合现象,配置管理员进行记录,并交由责任部门限期进行纠正,配置管理员负责纠正措施的验证;所有的不符合项报告均关闭后,才能发布新版本;发行管理通过配置审核后,经项目经理批准,由配置管理员负责生产新版本;交付管理这里“交付”是指从配置库中提取配置项,交付给客户或项目外的人员;交付出去的配置项必须有据可查,避免发生混乱;流程如下：1交付人向质量部申请；2质量部如果不同意交付,则拒绝交付配置项;如果同意交付,配置管理员应给出详细的交付清单；3交付人验收后签字;。
文件更改记录表目录1 范围 (1)1.1 标识 (1)1.2 系统概述 (1)1.3 文档概述 (1)1.4 与其他计划之间的关系 (1)2 引用文裆 (1)3 组织和职责 (1)4 一般要求 (2)4.1 “软件三库”的要求 (2)4.2 环境、管理工具要求 (2)4.3 访问和授权 (2)4.4 “软件三库”的备份要求 (2)5 软件配置管理活动 (2)5.1 配置标识 (2)5.2 配置控制 (2)5.3 配置状态记实 (3)5.4 配置审核 (3)5.5 软件发行管理和交付 (3)6 工具、技术和方法 (4)7 对供货单位的控制 (4)8 进度表 (4)9 注释 (4)1 范围1.1 标识本条应描述本文档所适用的系统和软件的完整标识，适用时，包括其标识号、名称、缩略名、版本号和发布号。
a）文档标识号：TN/x-DO-DS-V{N.xx}；b）标题：；c）软件名称；d）软件缩写：e）软件版本号。
1.2 系统概述本条应概述本文档所适用的系统和软件的用途。
它还应描述系统与软件的一般特性:概述系统开发、运行和维护的历史;标识项目的需方、用户、开发方和保障机构等;标识当前和计划的运行现场:列出其他有关文挡。
1.3 文档概述本条应概述本文档的用途和内容，并描述与它的使用有关的保密性方面的要求。
1.4 与其他计划之间的关系本条应描述本计划和其他项目管理计划的关系。
2 引用文裆本章应列出引用文档的编号、标题、编写单位、修订版及日期，还应标识不能通过正常采购活动得到的文档的来源。
3 组织和职责本条应描述软件配置管理机构的组成及各级软件配置管理机构的职责和权限:说明与软件配置管理相关的人员(如项目经理、部门软件配置管理组组长)在软件配置管理中的职责:描述上述人员之间的关系。
适用时，本条还应描述需方及用户等与软件配置管理机构之间的关系。
建议如下表：表-X4 一般要求4.1 “软件三库”的要求在软件开发、生产和维护过程中，各承研单位均针对如何建立“软件三库”（开发库、受控库、产品库）对项目进行管理提出具体要求。
