配置管理文档
项目名
格拉特尼美食梦工厂开发日期：2010-09-20至2011-01-14 称：
分类：配置管理文档指导教师：王崇文
团队：2013 页数：
修订记录
日期版本内容作者<11/3/2010> <1.0> 编写文档框架2013
<11/5/2010> <1.1> 确定基线内容2013
2013 <11/7/2010> <1.2> 将文件进行编号，和整理，并体现在文
档当中
小组成员
魏盛斌20072757 闫志鑫20072759
尹航20072760 郑然20072766
目录
目录 (2)
1引言 (3)
1.1目的 (3)
1.2术语定义 (3)
1.3参考资料 (3)
2软件配置 (5)
2.1软件配置环境 (5)
2.2软件配置项 (5)
2.3配置管理员 (6)
4 软件配置管理计划 (8)
4.1建立示例配置库 (8)
4.2配置标识管理 (9)
4.2.1文档 (9)
4.2.2程序 (9)
4.2.3基线 (9)
4.3配置库控制 (10)
4.3.1权限控制 (10)
4.3.2配置库的控制 (10)
4.3.3建立软件库 (10)
4.3.4软件配置更改 (10)
4.3.5配置文件清单的维护 (10)
4.4配置的检查和评审 (11)
4.5配置库的备份 (13)
4.6配置管理计划附属文档 (13)
5里程碑 (14)
7附录1 文档命名规定 (15)
7.1受控配置库文件命名规则 (15)
7.2非受控配置库文件命名规则 (15)
7.3提交文档文件命名规则 (15)
9附录2 文档编码规范 (17)
10附录3 帐号及权限管理 (18)
11附录4 配置库使用规定 (20)
1引言
1.1目的
本文档目的在于对格拉特尼美食梦工厂进行软件配置管理，提高软件质量，降低软件开发成本。
本文档内容主要参考研发中心相关的ISO程序和制度文档，并在这基础上整理成适合本项目的软件配置管理，为项目经理、配置管理员及相关人员提供日常的配置管理操作步骤。
1.2术语定义
软件配置管理：简称SCM（Software Configuration Management的缩写），是在项目开发中，标识、控制和管理软件变更的一种管理。配置管理的使用取决于项目规模和复杂性以及风险水平。软件的规模越大，配置管理就显得越重要。
基线：(BaseLine) 是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。
配置管理员：项目组中负责配置管理工作的角色，该角色可以兼职。在某一开发阶段通过评审或某一质量检查点通过审核后，配置管理员负责统一添加或修改相关文档的最新有效版本以及审批人签字。
配置标识：（Configuration Identification）对软件项目在开发过程中的资源进行标识，以便识别。
配置检查：（Configuration Audit）对软件配置管理过程中的行动进行检查。
1.3参考资料
《研发中心配置管理制度》
《产品的标识与可追溯性程序》
《开发手册》
2软件配置
2.1软件配置环境
2.1.1开发用计算机软件环境
软件名称作用
Windows 7/Windows XP/Windows
操作系统
Vista
Adobe Flash Player 10.x flash运行环境
Adobe Flex Builder 3 flash开发环境
TortiesSVN 配置管理软件
在整个项目过程或产品生命周期中,选择TortiesSVN作为配置管理工具。
2.1.2 硬件环境
无特殊要求。
2.1.3配置管理客户端
项目组成员在各自的计算机安装SVN客户端，项目组成员以分配的帐号访问配置服务器和登录配置管理系统，根据配置管理员设定的用户权限进项配置管理活动。
2.2软件配置项
在本项目的实施过程中，将配置库分为受控配置库和非受控配置库两种
受控配置库
在本项目开发实施的整个过程中，根据不同阶段的配置管理划分8个受控配置目录，只有配置管理员拥有增加和修改的权限，其它用户只有只读的权限。受控配置库的目录为：
00初始环境配置
01启动
02需求分析
03概要与详细设计
04编码
05测试
06安装部署
07项目管理与变更控制
初始配置库的根目录中包含依然合得来小组的配置文件清单，该文档包括本项目开发过程中应该提交的文档的清单，在实际开发过程中，根据实际情况，可以在清单中酌情修改、增加和删除需要提交的文档。
非受控配置目录
在本项目开发过程中，设立了非受控配置目录。设立非受控配置目录的目的是为了统一管理和存放开发过程中产生的临时文档和过程性文档，没有格式及命名上的严格要求，使项目组成员在思考、设计时不受太多的限制和约束，能够更有效地发挥个人能力，符合以人为本的原则。
在项目初期，设立了以下三个目录：
目录名称用途及说明
小组工作区用于保存小组的公共代码和集体协作的文档
个人代码提交区用于保存小组成员的个人代码，每个人都有单独的
代码目录
个人文档提交区用于保存小组成员的个人文档，每个人都有单独的
文档目录
在根据项目开发过程中，根据实际需要，可以酌情增加非受控配置目录。
2.3配置管理员
技术支持经理在项目中担任配置管理员的工作。配置管理员负责：
1.指定配置计划
2.定期的查看配置库更新的内容
3.定期通知大家对稳定版本进行下载
4.协助组长进行交付物的检查和评审。
3
4软件配置管理计划
4.1建立示例配置库
配置管理员在制定完计划后，建立符合本项目的配置管理库。配置库建立在TortiesSVN上，目录结构可按照示例配置库提供的目录。对于本项目来说，需要划分多个子系统，因此要在确定子系统的划分后，在不同阶段下分别建立各子系统的配置目录。
配置管理库建立完毕后，配置管理人员为小组其他成员分配帐号和权限
配置管理员应保管好配置管理工具的管理员权限，项目组中使用配置管理库的成员应该及时更改自己在配置管理工具的缺省设置密码。
图1 项目管理文档列表
4.1.1
4.2配置标识管理
4.2.1文档
根据配置管理计划和配置库中的文档清单，配置管理员要检查需要提交的文档是否都按时提交，文档数目是否符合，文档的标识、命名以及版本等是否符合程序规定。关于文档的命名请参见附件1 《文档命名规定》
4.2.2程序
所有属于该项目的程序、分程序、模块和程序单元，都要按照由项目组和配置管理员制订的软件系统的命名约定的规定来标识。
要求所有模块的源代码都需记录模块编号，且模块编号在整个系统中是唯一的。模块编号在系统设计完成之后，由项目组和配置管理员共同根据系统设计进行编制。
4.2.3基线
所有属于本项目及其各子系统的各类基线，首先要按照计划书、软件需求规格说明书、软件项目详细分析设计说明书的规定确定其技术内容，在整个软件项目开发过程中定义以下两类基线：
文档基线：本项目的文档基线的定义以里程碑的定义为准，将到达各阶段的里程碑时的文档作为基线，具体里程碑的定义参见第4节“里程碑”。
产品基线：产品基线包含两个，一个是系统上线时，一个是系统经过客户验证测试时，基线包含那时的所有程序代码和文档。
配置管理员负责在项目开发的每一个里程碑处、每一个阶段性的版本发布时负责为整个配置库设立书签，划定配置管理基线，并以文档的方式记录下这些书签的定义。
4.2.4
4.3配置库控制
4.3.1权限控制
配置管理员根据附录3《帐号及权限管理》设置和调整项目组成员对配置项的权限。
4.3.2配置库的控制
在项目开发和实施的整个过程中，配置管理员根据配置管理计划及管理规则对配置库应进行管理和控制。配置管理员负责检查项目组成员使用配置库是否正确。包括是否及时检入最新版本、是否添加了注释、是否及时更改配置状态，是否存在项目组成员修改了不属于自己负责的配置项，项目组成员是否完成了自己负责的配置项的检入，测试版本的构造是否从配置库中取出等。
4.3.3建立软件库
在项目的各个开发阶段，应建立起各阶段各子系统的软件开发库（软件开发工作区），同时建立起想对应的有关该系统及其子系统的软件受控库。在每个阶段结束或里程碑，需让各子系统提交相关的产品并送入软件受控库，由配置管理员统一管理，以后再有对产品的变更需求，应按照正常的变更程序来控制并检查相关的变更文档。当全部开发工作结束，需建立起软件产品库，将所有可交付的产品都送入软件产品库。
4.3.4软件配置更改
软件配置的更改管理适用于全部项目的所有文档和代码，其中包括整个项目的各个运行软件，也包括为项目专门开发的支持软件。
对该项目各个子系统及其专用支持软件的基线及其集成系统的任何修改，必须得到项目负责人的批准并在本项目软件质量管理专员处备案
才能进行配置更改；
●更改完成后的文档和代码等，需得到项目负责人认可，提交给配置管
理员后，由配置管理员签入受控配置库；
●受控配置库中的文档，在文档末尾必须有修改记录部分，包括修改
人、修改日期、修改内容等项，每次对于受控配置库中文档的修改，
必须填写这些项。
4.3.5配置文件清单的维护
●配置文件清单的维护由配置管理员维护；
●项目初期，配置管理员与项目组成员一起对开发过程中可能产生的文
档的进行预计，并在配置文件清单中列出这些文档及其大致的计划提
交时间；
●在实际开发过程中，文档提交可能会产生一些变化，如新增某些文
档、原计划的一些文档不再单独产生、文档计划提交日期的变更等，
项目组应该及时通知配置管理员，由配置管理员及时更改配置文件清
单中的相应项。
4.3.6
4.4配置的检查和评审
配置的检查和评审可通过配置管理制度的审核内容来进行检查。相关的审核内容如下表：
审核分类审核内容检查情况
发布审核发布文档是否清楚地定义发布的范围，包括应被纳入的
更改请求？
否所有已知缺陷/毛病(bug)是否已文档化？是
是否有适当的文档，它标识重建该发布所需的环境（编
译器版本、OS版本、compilation flags，等等）？
否
是否有适当的文档，它说明构成该发布的成分及成分的
版本？
是发布的所有项是否彼此同步（在时间上一致）？是
是否采用正确存储库中的正确成分的正确版本生成发
布？
是
存储库/配置项审
核存储库是否按SCM计划定义？否项是否已经进入正确的库？是是否按SCM计划中规定的命名约定项命名? 是是否按照SCM计划，规定项的版本号？是
是否按照SCM计划中规定的事件已经将所有项入库？
是例如：测试完成、客户的评审意见已采纳
项是否有所要求的文档以识别项、版本和更改历史？是
是否全部所要求的更改请求均已结束？是更改实施
审核
是否更改请求标识出全部拟更改的项？是
否更改请求中所标识的全部要更改的项均已更改，被QC
和在所要求的QC后入库？
是否可能在项的任何两个版本中间区分更改？是
项的文档是否足够，能向后追踪更改到相应的更改请
是求？
是否有恰当方法能回到以前的版本？是
是否对库作了恰当的备份? 是审核的其
他方面
是否已测试过从备份中恢复? 是
在群组成员的工作目录中是否有任何未经许可的成分？是
是是否有恰当的保密/批准手续以保证只有经授权的群组成
员才能进行入库/出库？
配置管理员应配合研发中心产品管理部定期对项目进行配置管理的审核。在审核过程中，提供所需要的配置管理计划及相关资料，在项目开发结束后，需提交所有关于项目的软件配置库。
4.4.1
4.5配置库的备份
在项目开发实施过程的各个阶段，配置管理员应定期做好软件配置库的备份，以防造成劳动成果的丢失而给整个项目及小组带来的严重损失。
在每个阶段或里程碑处在做完基线工作后应进行备份。备份文件应存放在不同的地方。
本项目的备份按如下方式进行：
?定期备份时间为每周备份一次
?当达到一个里程碑时，对配置库进行一次备份
?备份的文件要明确标明备份日期，除了在版本控制服务器中以外，还要在每个人电脑上进行备份
4.6配置管理计划附属文档
《配置文件清单》：记录项目开发过程中应该产生的一些文档、描述及其提交计划等内容，是执行配置管理及检查的重要依据。该文档在项目开始的初期建立，确定开发过程中需要提交的大部分文档，并在项目开发过程中根据实际情况稍做更新。
《模块清单》：模块清单记录了系统各个子系统、程序模块的名称并分别进行项目内的唯一编号，是所有模块的源代码需记录模块编号的依据。《模块清单》在系统设计完成之后，由项目组和配置管理员共同根据系统设计进行编制。
《文档命名规定》：参见附录1 《文档命名规定》
《帐号及权限管理》：参见附录3 《帐号及权限管理》
《配置库日常使用规定》：参见附录4 《配置库日常使用规定》4.6.1
软件开发项目配置管理工具的选择 通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报…… 每一个软件项目，无论是工程类项目，还是产品类项目，都必须经历需求分析、系统设计、编码实现、集成测试、部署、交付、维护和支持的过程。在这个过程中，将生成各种各样不同的工件，包括文档、源程序、可执行代码、支持库。更可怕的是，频繁出现的变更是不可避免的，因此面向如此庞大且不断变动的信息集，如何使其有序、高效地存放、查找和利用就成为了一个突出的问题。 针对这一问题，最早的开发人员尝试过的解决办法是通过手工来实现： 1)文档：每次修改时都另存为一个新的文件，然后通过文件名进行区分，例如"XXX 软件需求说明书V1.0，XXX软件需求说明书V1.1，XXX 软件需求说明书V2.0."，并且在文件中注明每次版本变化的内容； 2) 源代码：每次要修改时就将整个工程目录复制一份，将原来的文件夹进行改名，例如"XX 项目V1.0、XX 项目1.01、."，然后在新的目录中进行修改； 但是这种方法，不仅十分繁琐，容易出错，而且会带来大量的垃圾数据。如果是团队协同开发或者是项目规模较大时，还是会造成很大的混乱。很显然，这样简陋的方法是无法应对这一问题的。后来，有人尝试从制造工业领域引入了"配置管理"这一概念，通过不懈的研究与实践，最终形成了一套管理办法和活动原则，这也就是软件配置管理。 通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报。 常见的配置管理工具 正如前面所述，由于软件配置管理过程十分繁杂，管理对象错综复杂，如果是采用人工的办法不仅费时费力，还容易出错，产生大量的废品。因此，引入一些自动化工具是十分有裨益的，这也是做好配置管理的必要条件。 正是因为如此，市场上出现了大量的自动化配置管理工具，这些工具的实现原理与基本机制
项目配置管理过程规范文档种类：研发体系 发行范围：研发中心
变更记录
目录 1. 前言 (4) 1.1. 目的 (4) 1.2. 适用范围 (4) 1.3. 术语 (4) 2. 职责说明 (5) 3. 输入 (6) 4. 入口准则 (6) 5. 活动 (7) 5.1. 活动关系图 (7) 5.1.1. 配置管理流程图 (7) 5.1.2. 配置变更流程图 (8) 5.2. 活动描述 (8) 5.2.1. 制定配置管理计划 (8) 5.2.2. 建立配置库 (9) 5.2.3. 建立配置项 (9) 5.2.4. 基线建立及发布过程 (9) 5.2.5. 配置变更 (10) 5.2.6. 配置审计 (11) 5.2.7. 备份 (11) 6. 输出 (11) 7. 出口准则 (11) 8. 本过程裁剪规定 (11)
1. 前言 1.1. 目的 用于描述配置管理过程，规范配置管理的操作。 1.2. 适用范围 适用于在软件生命周期中对各类软件项目的配置管理活动。 1.3. 术语 CCB：Configuration Control Board，配置控制委员会，每个项目组需要建立项目级的CCB作为变更控制权威。CCB由PPQA、项目经理、测试经理、配置管理员构成，有时也可以包括客户代表、高层经理。CCB组长可以是PPQA或高层经理，但不能是项目经理。 Baseline：基线，是开发过程中标识出的里程碑所交付的一个或多个配置项，它有三个特征：（1）已经过正式的评审和批准；（2）作为项目发展和产品升级的基础。基线变更必须经过CCB审批。 配置审计：可以分为物理审计和功能审计。前者审查配置项的外在特征的正确性与一致性；后者审查配置项内容的正确性与一致性。 物理审计的内容包括： ?确认配置项标识的正确性； ?确认已受控配置项的更改是受到控制的； ?验证配置库内容与相应记录之间的一致性； ?验证配置管理活动与相应记录之间的一致性； ?验证配置管理工作是否符合适用的标准和规程； ?验证配置管理系统与系统备份的有效性、一致性等。 功能审计的内容包括： ?验证当前基线所含配置项对前一基线所含配置项的追溯性；
软件配置管理规范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
基于Microsoft.Visual.SourceSafe.2005(简称VSS2005)文档配置管理系统的建立V2.07 基于Microsoft.Visual.SourceSafe.2005（简称VSS2005）文档配置管理系统的建立 1 前言 一个好的项目，配以一个好的文档配置管理系统是非常必要的，不仅仅把项目研发过程的各个阶段性的文档有效地管理起来，同时也给项目组成员查询资料提供良好的公共平台。为管理和识别本项目所有关键文档和资料的状态提供了必要条件。 2 配置管理系统的基础 本文档所要做的配置管理系统就是基于Microsoft.Visual.SourceSafe.2005（简称VSS2005）文档配置管理系统的建立。 3 配置管理系统的建立 配置管理系统的名称是Microsoft.Visual.SourceSafe.2005（简称VSS2005）。 安装好VSS2005后程序菜单中应该已经有相应的快捷方式了，如下图： 该配置管理系统Microsoft.Visual.SourceSafe分为服务器端Microsoft Visual SourceSafe Administration和客户端Microsoft Visual SourceSafe两部分。
1 服务器端的主要使用方法是： 1). 启动VSS2005服务器端，进入服务器端环境。如下图： 2). File - > New database... （文件->新建数据库）。如下图： 弹出对话框如下图： 点击“下一步”，弹出对话框如下图： 点击“Browse”导入你希望存放安全数据的文件夹所在位置（本项目此文件夹位置为F：\safetydatalib，并将该文件夹设置为仅项目组成员才能完全访问），再点击“下一步”，由于F盘的盘符是FAT32文件系统，故会弹出警告信息，弹出对话框如下图： 盘符是FAT32格式则VSS2005权限设置功能会受限，可转换盘符到NTFS格式。本项目盘符采用FAT32格式，故点击“是”即可完成数据库的建立。 3). File - >Open Sourcesafe database... （文件->打开源安全数据库）。如下图： 弹出对话框如下图： 点击“Add”，弹出对话框如下图： 点击“下一步”，弹出对话框如下图： 点击“Browse”导入F：\safetydatalib\ srcsafe.ini后对话框显示如下图： 点击“下一步”，弹出对话框如下图：
份号：001 密级： XXXXXXXX项目 软件配置管理报告 XXXX-RPB-R01.00 XXXXXXXX公司 XXXX年XX月XX日
辑要页
文档修改记录
目次 1 范围 (1) 1.1标识 (1) 1.2系统概述 (1) 1.3文档概述 (1) 2 引用文挡 (1) 3 软件配置管理情况综述 (1) 4 软件配置管理基本信息 (1) 5 专业组划分及权限分配 (1) 6 配置项记录 (1) 7 变更记录 (2) 8 基线记录 (2) 9 入库记录 (2) 10 出库记录 (2) 11 审核记录 (2) 12 备份记录 (2) 13 测量 (2) 14 主释 (2)
1 范围 1.1 标识 本条应描述本文档所适用的系统和软件的完整标识，适用时，包括其标识号、名称、缩略名、版本号和发布号。 1.2 系统概述 本条应概述本文档所适用的系统和软件的用途。它还应描述系统与软件的一般特性;概述系统开发、运行和维护的历史;标识项目的需方、用户、开发方和保障机构等;标识当前和计划的运行现场;列出其他有关文档。 1.3 文档概述 本条应概括本文档的用途和内容，并描述与其使用有关的保密性考虑。 2 引用文挡 本章应列出引用文档的编号、标题、编写单位、修订版及日期，还应标识不能通过正常采购活动得到的文档的来源。 3 软件配置管理情况综述 本章应描述软件配置管理活动进展，与软件配置管理计划的偏差;软件配置管理活动与规程是否相符;对不符合项所采取的措施;完成软件配置管理工作的工作量等。 4 软件配置管理基本信息 本章应概述软件配置管理的基本信息，包括项目负责人、各级软件配置管理机构组成人员和负责人、软件配置管理所用的资源(如计算机、软件和工具)等。 5 专业组划分及权限分配 本章应列出项目专业组的划分、各专业组的成员以及各成员的权限分配，如专业组可分为项目负责人、开发组、测试组、质量保证组、配置管理组等，权限可分为读出、增加、替换、删除等。 6 配置项记录 本章所列出项目的所有配置项，包括配置项名称、配置项最后发布日期、配置项控制力度(控制力度可分为基线管理、非基线管理(受到管理和控制))、配置项版本变更历史、配置项变更累计次数等内容。
软件配置管理规范 流程 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) 在配置管理系统中, 基线就是一个配置项或一组配置项在其生命周期的不同时间点上经过正式评审而进入正式受控的一种状态这些配置项构成了一个相对稳定的逻辑实体, 而这个过程被称为基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素( 配置项) 的一个版本, 且只确定一个版本。一般情况下, 基线一般在指定的里程碑处创立, 并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制, 基线中的配置项被冻结”了, 不能再
产品/项目系统名称 配置管理计划 北京XXXX有限公司 200 年××月 1引言 1.1编写目的
编写的目的主要在于对所开发的软件系统规定各种必要的配置管理条款，以保证所开发出的软件能满足用户需求。 1.2背景 a.开发的软件系统的名称 列出本软件系统的中文全称、英文全称及英文表示简称。 b.开发的软件系统的最终用户或适用的领域； c.项目来源、主管部门等 1.3定义 列出本文件中涉及的专门术语定义和外文缩写的原词组。 1.4参考资料 列出涉及的参考资料。 2 管理 描述软件配置管理的机构、任务、职责和有关的接口控制。 2.1 机构 描述软件生存周期中各阶段中软件配置管理的功能和负责软件配置管理的机构。 说明项目和自项目与其他有关项目之间的关系。 指出在软件生存周期各阶段中的软件开发或维护机构与配置控制组的关系。 2.2 任务 描述在软件生存周期中各阶段的配置管理任务以及要进行的评审和检查工作，并指出各阶段的阶段产品应存放在哪一类软件库中（软件开发库、软件受控制库或软件产品库）。 2.3 职责 指出负责各项软件配置管理任务（如配置标识、配置控制、配置状态记录以及配置的评审与检查）的机构的职责； 指出上述机构与软件质量保证机构、软件开发单位、项目承办单位、项目委托单位以及用户等机构的关系。 说明软件生存周期各个阶段的评审、检查和审批过程中的用户职责以及相关的开发与维护活动。 指出与项目开发有关的各机构的代表的软件配置管理职责。 指出与其他特殊职责，例如为满足软件配置管理要求所必要的批准要求。 2.4 定义软件配置项（SCI） 包括： 1．系统约定 2．软件项目计划 3．软件需求文档 4．用户手册 5．设计文档
软件配置管理计划示例 作者：赵文锋计划名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．各子系统的配置管理人员具体负责实施各自的配置管理工作，并参与各子系统的功能配置检查和物理配置检查；
【最新整理，下载后即可编辑】 项目配置管理过程规范
文档种类：研发体系发行范围：研发中心
变更记录 息，以保证其可追溯性。
目录 1. 前言 (4) 1.1. 目的 (4) 1.2. 适用范围 (4) 1.3. 术语 (4) 2. 职责说明 (5) 3. 输入 (5) 4. 入口准则 (5) 5. 活动 (6) 5.1. 活动关系图 (6) 5.1.1. 配置管理流程图 (6) 5.1.2. 配置变更流程图 (7) 5.2. 活动描述 (7) 5.2.1. 制定配置管理计划 (7) 5.2.2. 建立配置库 (8) 5.2.3. 建立配置项 (8) 5.2.4. 基线建立及发布过程 (8) 5.2.5. 配置变更 (9) 5.2.6. 配置审计 (9) 5.2.7. 备份 (10)
6. 输出 (10) 7. 出口准则 (10) 8. 本过程裁剪规定 (10)
1. 前言 1.1. 目的 用于描述配置管理过程，规范配置管理的操作。 1.2. 适用范围 适用于在软件生命周期中对各类软件项目的配置管理活动。 1.3. 术语 CCB：Configuration Control Board，配置控制委员会，每个项目组需要建立项目级的CCB作为变更控制权威。CCB由PPQA、项目经理、测试经理、配置管理员构成，有时也可以包括客户代表、高层经理。CCB组长可以是PPQA或高层经理，但不能是项目经理。 Baseline：基线，是开发过程中标识出的里程碑所交付的一个或多个配置项，它有三个特征：（1）已经过正式的评审和批准；（2）作为项目发展和产品升级的基础。基线变更必须经过CCB审批。 配置审计：可以分为物理审计和功能审计。前者审查配置项的外在特征的正确性与一致性；后者审查配置项内容的正确性与一致性。 物理审计的内容包括： ?确认配置项标识的正确性； ?确认已受控配置项的更改是受到控制的；
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目的 控制对构成软件/硬件产品的各配置项的标识、管理、更改活动，保证配置项的完全性和正确性，防止非预期的使用，并能够有效的实现可追溯性。 2适用范围 适用于软件/硬件产品在整个生存周期中的控制管理活动。 3术语 ●配置：配置是指一个软件/硬件产品在生存周期的各个阶段所产生的 各个形式（机器可读或人工可读）和各种版本的文档、程序及其数 据的集合，该集合随着开发工作的进展而不断变化。 ●配置项：为了配置管理目的而作为一个单位来看待的硬件和/或软件 成分，或它们的集合体（软件项及开发文档都称为配置项）。 ●软件库：软件和有关文档说明的一个受控制的集合。目的是有助于 软件/硬件开发、使用和维护。包括开发库、受控库和产品库等。 ●开发库：指在软件生存周期的某一个阶段期间，存放与该阶段软件/ 硬件开发有关的计算机可读信息和人工可读信息的库。 ●受控库：指在软件/硬件生存周期的某一个阶段结束时，存放作为阶 段产品而释放的、与软件/硬件开发工作有关的计算机可读信息和人 工可读信息的库。配置管理就是对受控库中的各个软件项进行管理， 因此受控库也叫做配置管理库。 ●产品库：指在软件/硬件生存周期的组装与系统测试阶段结束后，存 放最终产品而后交付给用户运行或在现场安装软件库。 ●软件项：是指组成最终产品的源代码、中间文件、目标运行代码， 构成安装程序的源代码、中间文件、目标运行代码以及产品的联机 帮助说明文件（源代码包括程序代码、头文件、资源文件等）。 4职责 项目负责人是配置管理活动的总负责人。其主要职责是制定《配置管理计划》，组织配置管理活动的实施并对实施效果进行监督检查，协调配置管理活动中的有关事宜。
软件配置管理计划示例 计划名国势通多媒体网络传输加速系统软件配置管理计划 项目名国势通多媒体网络传输加速系统软件 项目委托单位代表签名年月日 项目承办单位北京麦秸创想科技有限责任公司 代表签名年月日 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 任务
软件配置管理工具Vss6.0实用指南 一、版本管理的必要性 如果说70年代的软件危机导致了软件工程思想的诞生和理论体系的发展，那么80～90年代尤其是90年代软件产业的迅猛发展导致了另一种新思想的产生和实现，这就是软件的版本管理。 只要参加过软件开发的人都清楚，现在的软件项目完全由一个人来完成是难以想象而且也是不可能的，通常是有一个研发小组来共同分析、设计、编码和维护，并有专门的测试小组对已完成编码调试的软件进行全面的测试。在软件开发这个庞大而复杂的过程中，需要涉及到各个方面的人员，信息的交流反馈不仅仅是在研发小组的成员之间及各个研发小组之间，还存在于客户和研发者之间。所有的这些交流反馈意见信息都有可能导致对软件的修改，小的可能只是对某个源文件中的某个变量的定义改动，大到重新设计程序模块甚至可能是整个需求分析变动。在这个工程中，由于软件开发所固有的特征，可能会形成众多的软件版本，而且我们并不能保证不出现错误的修改，而这样的一个困难局面却又非常现实地摆在项目开发管理者的面前，他/她该如何有效地解决这些问题，具体地说就是如下一些问题： 1.怎样对研发项目进行整体管理； 2.项目开发小组的成员之间如何以一种有效的机制进行协调； 3.如何进行对小组成员各自承担的子项目的统一管理； 4.如何对研发小组各成员所作的修改进行统一汇总； 5.如何保留修改的轨迹，以便撤销错误的改动； 6.对在研发过程中形成的软件的各个版本如何进行标识，管理及差异识辨等等。 一个非常直接的反应，我们必须要引进一种管理机制，一个版本管理机制，而且是广义上的版本管理，它不仅需要对源代码的版本进行管理，而且还要对整个项目进行管理。以往的那种被誉为具有良好编程风格的做法，诸如在对他人的源程序进行修改时注释修改原因，修改人和日期，如果是多个成员同时进行了修改，那么需要进行及时的人工的差异比较和综合以便形成一个统一的新版本。这种做法在当前的大型软件的开发中已经越来越没有空间了，可以说是一种以小作坊的形式来面对软件的社会化大生产，再也不可能行得通了。 其实，版本管理的思想很早就存在于软件开发者的头脑之中，只是以往的认识没有现在人们所意识到的那样迫切。UNIX 的程序开发系统较早就提供了能够进行开发小组中源代码版本管理的工具，现在的Linux更是提供功能强大的能够跨平台的版本管理器，国外公司的基于Windows的版本管理器也已经有了比较成熟的产品，国内的研究单位如北京大学计算机系CASE实验室也在致力于这方面的工作。在众多的成熟产品和试验产品中，这里只将对使用比较广泛，有较大用户前景且又能较易获得的版本管理器产品Microsoft公司的Visual SourceSafe6.0进行详细的介绍，针对普通的研发小组的解决方案，及具体的实现。 二、Visual SourceSafe6.0(VSS6.0)简介 VSS6.0现在是作为Microsoft Visual Studio6.0这个开发产品家族的一员，如Visual C++6.0和Visual J++6.0一样。 1.VSS的简单工作原理 Microsoft的VSS6.0解决了软件开发小组长期所面临的版本管理问题，它可能有效地帮助项目开发组的负责人对项目程序进行管理，将所有的项目源文件（包括各种文件类型）以特有的方式存入数据库。开发组的成员不能对该数据库中的
项目名称（The English Name）配置管理计划 XXX项目小组
修订表
审批记录
目录 1.引言 (5) 1.1目的 (5) 1.2适用范围 (5) 1.3参考资料 (5) 1.4术语和缩略语 (5) 2.人员与责任 (5) 3.用于配置管理的软硬件资源 (6) 4.配置库结构与权限 (6) 4.1配置库列表 (6) 4.2配置库结构 (6) 4.3人员权限 (6) 5.配置项计划 (7) 6.基线计划 (7) 7.配置库备份计划 (7)
1.引言 1.1目的 本计划的目的是定义软件项目组进行配置管理活动、任务和责任；定义支持配置管理的活动及报告的工具、技术和方法。 1.2适用范围 本计划定义项目组在项目期间的所有配置管理活动。 1.3参考资料 《配置管理指南》 《配置项变更规程》 《配置审核规程》 《基线生成产品规程》 1.4术语和缩略语 CCB：软件配置控制委员会、变更控制委员会 2.人员与责任 提示： （1）根据《项目计划》中的角色分配，确定配置管理员，CCB（配置控制委员会）成员。 （2）CCB的人数根据项目规模而定。一般地，项目经理是CCB的负责人。
3.用于配置管理的软硬件资源 提示： （1）配置管理员确定本项目的配置管理软件。例如采用Microsoft公司的Visual SourceSafe、Excel 或者CVS。 （2）配置管理员根据所采用的配置管理软件，确定计算机资源（考虑内存、外存、CPU等）。 4.配置库结构与权限 4.1配置库列表 4.2配置库结构 以课堂上讲授的配置库结构为主，各小组可以根据自己组的实际情况来调整。 4.3人员权限
配置管理文档
项目名 格拉特尼美食梦工厂开发日期：2010-09-20至2011-01-14 称： 分类：配置管理文档指导教师：王崇文 团队：2013 页数： 修订记录 日期版本内容作者<11/3/2010> <1.0> 编写文档框架2013 <11/5/2010> <1.1> 确定基线内容2013 2013 <11/7/2010> <1.2> 将文件进行编号，和整理，并体现在文 档当中 小组成员
魏盛斌20072757 闫志鑫20072759 尹航20072760 郑然20072766 目录 目录 (2) 1引言 (3) 1.1目的 (3) 1.2术语定义 (3) 1.3参考资料 (3) 2软件配置 (5) 2.1软件配置环境 (5) 2.2软件配置项 (5) 2.3配置管理员 (6) 4 软件配置管理计划 (8) 4.1建立示例配置库 (8) 4.2配置标识管理 (9) 4.2.1文档 (9) 4.2.2程序 (9) 4.2.3基线 (9)
4.3配置库控制 (10) 4.3.1权限控制 (10) 4.3.2配置库的控制 (10) 4.3.3建立软件库 (10) 4.3.4软件配置更改 (10) 4.3.5配置文件清单的维护 (10) 4.4配置的检查和评审 (11) 4.5配置库的备份 (13) 4.6配置管理计划附属文档 (13) 5里程碑 (14) 7附录1 文档命名规定 (15) 7.1受控配置库文件命名规则 (15) 7.2非受控配置库文件命名规则 (15) 7.3提交文档文件命名规则 (15) 9附录2 文档编码规范 (17) 10附录3 帐号及权限管理 (18) 11附录4 配置库使用规定 (20) 1引言
XX项目 平台配置管理计划文件修改控制 XX公司 2015年5月
目录 第1章引言 (3) 1.1.目的 (3) 1.2.术语定义 (3) 1.3.参考资料 (3) 第2章软件配置 (4) 2.1.软件配置环境 (4) 2.1.1 服务器软件环境 (4) 2.1.2 硬件环境 (4) 2.1.3 配置管理客户端 (4) 2.2.软件配置项 (4) 2.2.1 受控配置库 (4) 2.2.2 非受控配置目录 (5) 2.3.配置管理员 (5) 第3章软件配置管理计划 (4) 3.1 建立示例配置库 (4) 3.2 配置标识管理 (4) 3.3 配置库控制 (5) 3.3.1 权限控制 (5) 3.3.2 配置库的控制 (5) 3.3.3 建立软件库 (5) 3.3.4 软件配置更改 (5) 3.4 配置的检查和评审 (6) 3.5 配置库的备份 (7) 3.6 配置管理计划的修订 (7) 3.7 配置管理计划附属文档 (8) 第4章里程碑 (9) 附录1 文档命名规定 (1) 1、受控配置库文件命名规则 (1)
2、非受控配置库文件命名规则 (1) 3、提交文档文件命名规则 (2) 附录2 帐号及权限管理 (3) 附录3 配置库使用规定 (5)
第1章引言 1.1.目的 本文档目的在于对XX项目进行软件配置管理，提高软件质量，降低软件开发成本。 本文档内容主要参考研发中心相关的制度文档，并在这基础上整理成适合本项目的软件配置管理，为项目经理、配置管理员及相关人员提供日常的配置管理操作步骤。 1.2.术语定义 软件配置管理：简称SCM（Software Configuration Management 的缩写），是在项目开发中，标识、控制和管理软件变更的一种管理。配置管理的使用取决于项目规模和复杂性以及风险水平。软件的规模越大，配置管理就显得越重要。 基线：(BaseLine) 是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。 配置管理员：项目组中负责配置管理工作的角色，该角色可以兼职。在某一开发阶段通过评审或某一质量检查点通过审核后，配置管理员负责统一添加或修改相关文档的最新有效版本以及审批人签字。 配置标识：（Configuration Identification）对软件项目在开发过程中的资源进行标识，以便识。 配置检查：（Configuration Audit）对软件配置管理过程中的行动进行检查。 1.3.参考资料 暂无
XXX项目配置管理计划 xxxxxxxxxxxxxxx公司20xx 年xx月xx 日
文档编号：XXXXXXXX-XXX-XXX 版本号：1.00 项目名称:XXXX项目 文档名称: 版本修改内容描述修改人日期备注1.0 第一版xxx 2014.6.3 1.01修正了……xxx 2014.6.3 批准人：日期：审核人：日期： 公司名称：xxxxxxxxxxxxxxxxxx有限公司 地址：xxxxxxxxxxxxxxxxxxxxxxxxx 电话：010-xxxxxxxx 网址：https://www.doczj.com/doc/2816857704.html, 邮箱：mengsuran@https://www.doczj.com/doc/2816857704.html,
目录 1. 引言 (1) 1.1 目的 (1) 1.2 术语定义 (1) 1.2.1软件配置管理 (1) 1.2.2 配置管理 (1) 1.2.3 配置项 (1) 1.2.4 基线 (1) 1.2.5 变更控制 (2) 1.2.6 配置审计 (2) 1.3 参考资料 (2) 2. 软件配置 (3) 2.1 软件配置环境 (3) 2.1.1服务器软件环境 (3) 2.1.2 硬件环境 (3) 2.1.3 配置管理客户端 (3) 2.2 软件配置项 (3) 2.2.1 受控配置项 (3) 2.2.2 非受控配置项 (4) 2.3 配置管理员 (4) 2.3.1 设立的必要性 (4) 2.3.2 主要职责 (4) 3. 软件配置管理计划 (4) 3.1 建立示例配置库 (4) 3.2 配置标识管理 (6) 3.2.1文档 (6) 3.2.2 程序 (6) 3.2.3 基线 (6) 3.3 配置库控制 (6) 3.3.1 .权限控制 (6) 3.3.2 配置库控制 (6) 3.3.3 建立软件库 (6) 3.3.4软件配置更改 (7) 3.3.5配置文件清单的维护 (7) 3.4 配置的检查和评审 (7) 3.5 配置库的备份 (8) 3.6 配置管理计划的修订 (9) 3.7 配置管理计划附属文档 (9) 4. 里程碑 (10)
配置管理规范
配置管理规范模板 目录 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为例描述配置管理库的建立及各配置项的控制方法。各项目在开始时，均应建立以下几项子项目，进行分阶段管理。
软件配置管理计划(SCMP) 说明 《软件配置管理计划》(SCMP)说明在项目中如何实现配置管理。 软件配置管理计划的正本格式如下： 1引言 本章应分成以下几条。 1.1标识 本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号、发行号。 1.2系统概述 本条应简述本文档适用的系统和软件的用途。它应描述系统与软件的一般性质；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；并列出其他有关文档。 1.3文档概述 本条应概括本文档的用途与内容，并描述与其使用有关的保密性与私密性要求。 1.4组织和职责 描述软件配置管理(SCM)负责人和软件配置控制委员会(SCCB)的组成以及他们在项目中的职责和权限；说明与项目配置管理相关的人员，如项目经理、部门SCM组长的职责；描述以上人员之间的关系。 为了能够清晰的表述，可选用图表的方式进行说明。 1.5资源 描述项目配置管理活动所需的各种资源，包括人员、培训、工具、设备、设施等等。其中人员是指人力成本，它是根据项目开发计划中的总工时计算得出的。 2引用文件 本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。本章还应标识不能通过正常的供货渠道获得的所有文档的来源。 3管理 描述负责软件配置管理的机构、任务、职责及其有关的接口控制。 3.1机构 描述在各阶段中负责软件配置管理的机构。描述的内容如下： a.描述在软件生存周期各阶段中软件配置管理的功能和负责软件配置管理的机构； b.说明项目和子项目与其他有关项目之间的关系； c.指出在软件生存周期各阶段中的软件开发或维护机构与配置控制委员会的相互关系。 3.2任务 描述在软件生存周期各阶段中的配置管理任务以及要进行的评审和检查工作，并指出各个阶段的阶段产品应存放在哪一类软件库中(软件开发库、软件受控库或软件产品库)。 3.3职责 描述与软件配置管理有关的各类机构或成员的职责，并指出这些机构或成员相互之间的关系： a.指出负责各项软件配置管理任务(如配置标识、配置控制、配置状态记录以及配置的评审与检查)的机构的职责； b.指出上述机构与软件质量保证机构、软件开发单位、项目承办单位、项目委托单位以及用户等机构的关系； c.说明由本计划第3.2条指明的生存周期各阶段的评审、检查和审批过程中的用户职