软件配置管理指南
软件配置管理指南编号：PRO-SCMP
版本 1.0
变更记录
1引言
软件配置管理的目的是在项目整个软件生存周期过程中建立和维护软件项目产品的完整性和一致性。
软件配置管理包括确认在给定时间点上软件的配置（即选定的软件工作产品及其描述），系统地控制对配置的更改，并维护在整个软件生存周期中配置的完整性和可跟踪性。
置于软件配置管理之下的工作产品包括：软件过程资产（例如软件过程改进中的所有文档），交付给顾客的软件产品（例如软件需求文档和代码），内部使用的相关软件产品，以及为完成这些软件产品而生成的中间产品。这些产品通常置于产品基线库中并由专门人员进行管理和控制。
软件配置管理过程需要达到的目标包括：
1.保证软件项目的配置管理活动是有计划的。
2.所选择的软件工作产品是确定的、受控的、可访问和可用的。
3.对已经确定的软件工作产品的变更是受控的。
4.相关部门和人员能及时获知软件基线库的状态、变更和变更内容。
1.1目的
本计划定义了项目的配置管理流程，目的是为了在整个软件生命周期中，控制构成软件产品的各配置项的标识、变更等活动，从而建立并维护软件产品的完整性、正确性、一致性和可追溯性。
1.2范围
本软件配置管理计划适用于整个软件生存周期过程中已纳入配置管理库的配置项的活动。置于配置管理系统下的工作产品通常包括：
1.各种标准（代码书写标准、设计标准等）
2.项目计划（开发计划、质量保证计划和配置管理计划等）
3.软件需求说明书及相关的文档和静态原型
4.设计文档
5.软件源代码
6.测试计划、测试程序和数据
7.软件操作手册
8.各种跟踪记录、测试记录、评审报告等
9.过程改进文档
10.其它相关的资料库（电子的和非电子的文档）
11.其他和软件开发及管理相关的和必要的文档
1.3术语定义
1.软件配置项（SCI）
软件配置项（Software Configuration Item）为了配置管理的目的而作为一个基本的独立单位来看待的软件成分或它们的集合体，如外部提交的软件产品、项目成果(代码、文档和数据)以及项目内部使用的支持工具(如文档测试用例软件工具)等。在多数的软件配置管理系统中，最基本的软件配置项是以磁盘文件的形式存放和管理的。
2.基线（Baseline）
已经通过正式评审和认可，作为下一步开发的基础，并且只有通过正式的更改控制规程才能进行更改的配置项。
3.软件配置控制委员会（SCCB）
Software Configuration Control Board 缩写，软件配置控制委员会
4.配置管理库
分为开发库、测试库、基线库(受控库)和产品库。
5.开发库
在软件生命周期的某一阶段期间，存放与该开发活动相关的配置项及相关信息的库。
6.测试库
存放单元测试之后、系统测试结束之前的，与测试相关的配置项。
7.基线库
在软件生命周期的某一阶段结束时，存放作为阶段成果而释放的、与开发活动相关的配置项及相关信息的库。纳入基线库的配置项的更改必须遵照《变更过程指导》进行。
8.产品库
项目成果正式提交用户前，SCM在项目经理的指导下从基线库中提取构成最终产品的配置项。
9.软件配置管理（SCM）
Software Configuration Management缩写，软件配置管理
10.软件工作产品（Software Workproduct）
作为定义、维护或使用软件过程的一部分所生成的任何人工制品。它包括过程描述、计划、规程、计算机程序和相联的文档。
11.同行评审（Peer Review）
由一个软件工作产品生成者的同行遵循已定义的规程对产品作的评审，目的在于标识出缺陷和改进之处。
2管理
2.1任务
在软件工程化生产的各个阶段中，与本阶段的阶段产品有关的全部信息在软件开发库存放，与之前各阶段的阶段产品有关的信息则在软件基线库(受控库)存放。在研制与开发阶段，开发者和开发小组组长有权对本阶段的阶段产品作必要的修改；但是如果开发者或开发小组长认为有必要个性前面有关阶段的阶段产品时，就必须通过项目的配置管理小组办理正规的审批手续。因此，软件开发库属于开发该阶段产品的开发者管理，而软件基线库(受控库)由项目的配置管理小组管理。软件经过组装与系统测试后，应该送入软件产品库，如欲对其修改，必须经软件配置管理小组研究同意，然后报项目总体组组长批准。
2.2角色与职责
1.SCCB
每个项目设立一个SCCB，负责指导和控制配置管理的各项具体活动的进行，为项目经理的决策提供建议。其具体职责为以下几项：定制访问控制；制定常用策略；建立、更改基线的设置，审核变更申请；根据配置管理员的报告决定相应的对策。
SCCB的人员组成主要包括：客户（必要时）、客户经理、项目经理、开发经理、系统分析员、配置管理员、测试代表、QA等，具体人员的分配应在配置管理计划中予以明确。
SCCB组长在项目的配置管理计划中指定，项目经理不任职SCCB组长。其职责为组织项目中SCCB的相关活动，代表SCCB组签名审批，SCCB列表签名不变。
2.项目经理
项目经理是整个软件研发活动的负责人，他根据SCCB的建议批准配置管理的各项活动并控制它们的进程。其具体职责包括：制定和修改项目的组织结构和配置管理策略；批准、发布配置管理计划；决定项目起始基线和开发里程碑；接受并审阅配置控制委员会的报告。
3.项目级SCM管理员
负责项目组配置管理库的配置管理活动：制定配置管理计划；根据配置管理计划执行各项管理任务，并定期向SCCB提交报告；负责项目基线库和开发库中各配置项的管理与维护；执行版本控制和变更控制方案；完成配置审计并提交报告；对开发人员进行相关的培训；识别软件开发过程中存在的问题并拟就解决方案。
每个项目设置固定的配置管理员，一个配置管理员可以同时兼多个项目。
4.公司级SCM管理员
接收项目级SCM管理员提交的配置管理相关报告，协调解决项目配置管理中出现的问
题。
5.项目组成员
根据《配置管理计划》执行相关任务。
6.项目归档管理员
负责项目结项归档或阶段归档的相关文档资料的统计和管理，确认并清点项目归档清单的一致性。
7.备份人
由项目经理指定，可以由SCM管理员或项目组其他成员担任。
8.QA
在项目实施过程中监控项目的配置管理过程和报告，保证质量标准和完整性；验收时，与SCM管理员及相关技术人员等进行基线审计活动，检查基线库中配置项的一致性和符合性，与其共同完成《基线审计报告》，同时还需填写《配置管理检查表》。
以上角色可视实际情况在配置管理计划中制定。
2.3软件配置管理过程
配置管理过程包括产品库管理过程（主要角色为公司级配置管理员）和项目配置管理过程（主要角色为项目级配置管理员、项目经理、SCCB）。
成品库的管理过程和项目的配置管理过程类似，区别在于从事管理活动的角色不同。对于公司成品库的管理由公司级的配置管理员来完成，主要包括服务器安装，成品入库、成品变更，成品出库，成品库审计和成品库配置管理活动统计。
成品库管理过程如图2-1所示：
图2- 1成品库管理的基本过程
项目配置管理的主要角色是项目级配置管理员，SCCB，项目经理。
图2-2是项目中配置管理的完整过程，其中配置管理计划是项目进行SCM活动的指南。
图2- 2 配置管理的基本过程
在第4部分，会详细介绍各个过程的活动。
3规范与约定
3.1目录结构
开发库目录结构：
a、工作产品目录（按软件生命周期划分）
b、源代码目录（执行文件和编译后的类文件不纳入配置管理）
c、安装盘目录
d、CMM文档目录
e、受控文档目录（用来存放不需要入基线库的过程文档，所有的项目组成员对此目录的文档都是R权限，配置管理员除外）
测试库、基线库的目录结构同开发库的a、b、c三项。
3.2命名规范
1．文档：
项目名称+”-” + 项目编号+ “-“ + 文档名称缩写。配置项名称中不需要包含版本信息。
2．源码和可执行代码：
源码和可执行代码使用项目自行定义的相应命名规则。
3.3版本定义规范
版本由版本号来标识，用于定义整个软件开发生命周期中所产生的成果。它可以用于描述一个单一的软件配置项的演变过程，也可以用于描述由多个配置项组成的产品的演变过程。
3.3.1版本号定义规范
版本号：Vx.y.z
?V代表版本(V ersion)
?…x?代表主版本号，初始值为1，当发生重大的版本升级替代时，通过SCCB审批，可以加1
?…y?代表版次号，初始值为0，当文档内容有一定变动(增加、删除、更改)，对系统产生实质性的影响时，版次号升一位数字
?…z?代表版变更号，初始值为0，当文档内容有一定变动(增加、删除、更改)，对系统产生非实质性的影响时，版次号升一位数字
在所有的版本号标识中，若版本号的前一位改变，则后面所有位全部归零。
3.3.2程序(代码、数据)版本规范
1．开发库版本号标识规范
版本标识形式为：“Vx.y.z”
通常情况：在纳入基线后才有正式的版本号，之前可以用标签的方式进行标识。标签的形式可以参照版本号标识规则进行。
2．测试库版本号标识规范
版本标识形式为：“Vx.y.z”。
开发库的配置项导入测试库后其版本标识的后2位全清零；而测试库的配置项导入基线库其版本标识不变。
3．基线库版本号标识规范
版本标识形式为：“Vx.y.z”。由SCM管理员对进入基线库的各模块的程序及文档的版本号进行分配，填写《配置项关系表》。
开发库的配置项在初次纳入基线时，由SCM管理员与项目负责人、产品负责人共同协商后，分配给初始的版本标识”Vx.0.0”，并严格按照版本控制的原则进行版本管理。
4．产品库版本号标识规范
版本标识形式为：“Vx.y.z”。
发布产品时，SCM与项目负责人共同确定发布产品的版本号，并填写《配置项关系表》。
对内发布产品时，项目负责人可以考虑提供相应的文档，表明构成软件产品的各配置项的版本情况，包括用于开发的工具的版本。
产品及其配置项的版本定义参考如下：
product_Vx.y.z(product为项目组定义的最终产品名称)
如: PB_kunming_CCB V1.0.2(昆明建行大前置系统V1.0.2)
产品中配置项名称举例：(其中各配置项名称为项目组各自定义)
middleware_V3.1.1(中间件V3.1.1)
AIX_V5.2(运行环境的AIX版本号为V5.2)
3.3.3ID编码规范
测试用例编码分三段，各段用一横线隔开，形式如：“TC-”+测试阶段代号+“-”+“功能模块编号”+“-”+两位顺序号。
其中，测试阶段代号中，DY代表单元测试，JC代表集成测试，XT代表系统测试，YS 代表验收测试，GN代表功能测试。
例如，结帐模块的功能测试用例的某一测试用例编码为：TC-GN-305-01
4软件配置管理活动
4.1配置管理计划
4.1.1流程
4.1.2主要活动
?确定项目级SCM管理员。
?项目级SCM管理员和项目经理确定项目类型并明确要从软件过程资产库中获得相应的配置项（标识、版本）。
?确定配置管理工具。
?项目级SCM管理员和项目经理一起划分和确定软件配置项（SCI）。
配置项是配置管理中的最小单位，文档可以为独立的一个软件配置项，如果一个软件配置项包含多个文档，配置项对应一个目录名称；源代码和安装程序可以以文件的形式，也可以以一个目录或者Package作为一个软件配置项。
?项目级SCM管理员与项目经理一起确定配置管理需要的目录结构
?项目级SCM管理员为SCI定义命名规范和版本控制方法
?项目级SCM管理员确定备份策略。
?项目级SCM管理员根据审批通过的PDSP中定义的基线库内容，整理出基线产品及入库时间，同时定义基线审计时间。
?项目级SCM管理员书写《软件配置管理计划》，规定在项目开发过程中配置管理活动、要求等，将其同开发计划一起提交给SCCB和控制主管审批，审批通过后方可
纳入基线库。
4.2建立配置环境
4.2.1主要活动
?项目组启动时，项目组负责人指定SCM管理员，确定项目组成员及其他相关人员对配置管理库的访问控制权限；
?SCM管理员与项目经理商议确定配置管理工具(CVS)、基线库的目录结构、基线等；
?SCM管理员建立配置管理环境，包括安装CVS，建立开发库和基线库的工作区及其目录结构。
CVS的配置与使用请参考《CVS指导手册》。
4.3开发库管理
4.3.1管理流程
4.3.2主要活动
包括：
?SCM管理员设置项目组成员对开发库的访问控制权限；
?SCM管理员负责将配置项导入开发库，并按照《配置管理计划》要求存放在相应目录下；
?开发组成员对配置项进行相关操作：配置项检出—修改—配置项检入；
?对配置项进行评审，评审通过后提交SCCB审批，申请纳入基线库；若审批未通过，则继续对配置项进行修改；若审批通过，则文档直接纳入基线库，代码应先纳入测
试库；
?SCM管理员对以上活动进行监控。
4.4测试库管理
4.4.1管理流程
4.4.2主要活动
包括：
?SCM管理员设置项目组成员对测试库的访问控制权限；
?SCM管理员负责将配置项导入测试库，并按照《配置管理计划》要求存放在相应目录下；
?测试组成员对配置项进行相关操作：配置项检出—测试—配置项检入；
?测试库中的配置项经过测试、评审，评审通过后提交SCCB审批，申请纳入基线库；
若审批未通过，则继续对配置项进行测试、修改；若审批通过，则纳入基线库；
?SCM管理员对以上活动进行监控。
4.5基线库管理
4.5.1管理流程
4.5.2主要活动
基线入库：
由项目经理填写《基线入库申请表》，提出书面的基线入库申请，如果按计划已经到了基线入库时间，而项目经理尚未提出基线入库申请时，则SCM管理员负责提醒
项目经理进行基线入库申请
?项目经理提出基线入库申请，经过SCCB审批后，由SCM管理员导入基线库；
?SCM管理员填写《基线变更日志》；
?SCM管理员更新《软件配置项状态报告》，并通知相关人员；
?SCM管理员对以上活动进行监控。
基线变更：
?由项目经理填写《软件变更申请表》，提出书面的基线变更申请，说明变更的原因、变更的内容，明确需要变更的配置项，其他不受变更影响的配置项，变更的解决方
法等。
?项目经理提出基线变更申请后，由SCCB签字审批，SCCB中的客户经理和客户（必要时）主要负责审批需求基线的变更；项目经理和系统分析员主要负责审批设计和
系统分析基线的变更；开发经理主要负责审批源代码基线和测试基线的变更。
?项目级SCM管理员依据SCCB签字认可的基线变更申请，将相关内容检出（Check Out）并交给项目经理。
?SCM管理员填写《基线变更日志》
?由SCM管理员更新《软件配置项状态报告》，并通知相关人员。
?变更结束后入库(同基线入库流程)。
4.6产品库管理
项目成果在正式提交用户前，SCM管理员在项目经理的指导下从基线库中提取构成最终产品的配置项，并纳入产品库。最终产品须经SCCB审批通过后方可正式提交给用户，SCM 负责对产品库的管理，其构成配置项的修改按照《变更过程指导》执行。
项目结项时SCM管理员配合项目经理将产品库移交给项目归档管理员，该项活动与该项目的结项、工作成果归档同时进行。
4.7发布
发布是指将软件项目开发活动中所产生的最终成果，对外部客户予以公布和递交的活动。发布可以是同一项目中的各个独立的软件产品的发布，如对公系统、清算系统；也可以是不同时期发布同一软件产品的不同版本，如增量模型中不同Release版本的发布活动。
4.7.1角色与职责
?发布人：通常指提供用于发布的软件产品的小组负责人或项目经理。
?项目经理：指导SCM管理员完成发布的活动，并对发布活动负责。
?SCM管理员：在项目经理的指导下，按照《配置管理计划》中发布计划的要求，从基线库中提取构成最终产品的配置项，并纳入产品库。编写《软件发布通知》；进行介质检查，并将软件成果介质分发给接受人。SCM管理员对发布产品中各配置项的完整性及其与产品的一致性负责。
?SCCB：对配置项从基线库进入产品库的活动进行审批。
?QA：与SCM管理员及技术负责人等进行基线审计，共同完成《基线审计报告》。
4.7.2流程
4.7.3主要活动
?项目经理根据发布计划，结合实际的开发进度、测试结果、评审结果等同意本次发布；
?发布人遵照发布计划指导SCM管理员从基线库中提取用于发布的各配置项；
?SCM管理于与QA及技术负责人等进行基线审计，共同完成《基线审计报告》；?基线审计通过后，SCM管理员编写《软件发布通知》并提交SCCB进行审批；
?《软件发布通知》经SCCB审批通过后，SCM管理员将通过审计的软件产品纳入产品库；
?SCM管理员准备发布介质，进行介质测试检查；
?发布人将软件产品及相关文档移交给接受人；
?QA监督整个过程的执行。
4.8关闭开发库
主要活动包括：
1、项目结束以项目移交结束为准。
2、开发库关闭作为项目结束、项目组解散的标志，由项目经理提出，由SCM管理员执行，并由SCM管理员以电子邮件的形式通知项目组所有成员。
3、最后的基线产品进入产品库，所有的文档进入软件过程资产库。
4、开发库关闭前需要做一次全备份，备份到磁带上，并加以标记。
软件开发项目配置管理工具的选择
软件开发项目配置管理工具的选择 通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报…… 每一个软件项目，无论是工程类项目，还是产品类项目，都必须经历需求分析、系统设计、编码实现、集成测试、部署、交付、维护和支持的过程。在这个过程中，将生成各种各样不同的工件，包括文档、源程序、可执行代码、支持库。更可怕的是，频繁出现的变更是不可避免的，因此面向如此庞大且不断变动的信息集，如何使其有序、高效地存放、查找和利用就成为了一个突出的问题。 针对这一问题，最早的开发人员尝试过的解决办法是通过手工来实现： 1)文档：每次修改时都另存为一个新的文件，然后通过文件名进行区分，例如"XXX 软件需求说明书V1.0，XXX软件需求说明书V1.1，XXX 软件需求说明书V2.0."，并且在文件中注明每次版本变化的内容； 2) 源代码：每次要修改时就将整个工程目录复制一份，将原来的文件夹进行改名，例如"XX 项目V1.0、XX 项目1.01、."，然后在新的目录中进行修改； 但是这种方法，不仅十分繁琐，容易出错，而且会带来大量的垃圾数据。如果是团队协同开发或者是项目规模较大时，还是会造成很大的混乱。很显然，这样简陋的方法是无法应对这一问题的。后来，有人尝试从制造工业领域引入了"配置管理"这一概念，通过不懈的研究与实践，最终形成了一套管理办法和活动原则，这也就是软件配置管理。 通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报。 常见的配置管理工具 正如前面所述，由于软件配置管理过程十分繁杂，管理对象错综复杂，如果是采用人工的办法不仅费时费力，还容易出错，产生大量的废品。因此，引入一些自动化工具是十分有裨益的，这也是做好配置管理的必要条件。 正是因为如此，市场上出现了大量的自动化配置管理工具，这些工具的实现原理与基本机制
软件配置管理过程指导说明书(超级实用)
软件配置管理过程指导说明书
目录 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）。 配置审计：可以分为物理审计和功能审计。物理审计审查配置项的外在特征的正确性与一致性，主要考查软件受控库的结构、内容及其它相关信息，以验证基线和描述它的文档的一致性；功能审计审查配置项内容的正确性与一致性，主要考核配置项在实现功能上的一致性，功能审计主要通过评审和测试报告体现。 物理审计的内容包括： ? 确认配置项标识的正确性； ? 确认已受控配置项的更改是受到控制的； ? 验证配置库内容与相应记录之间的一致性； ? 验证配置管理活动与相应记录之间的一致性； ? 验证配置管理工作是否符合适用的标准和规程； ? 验证配置管理系统与系统备份的有效性、一致性等。 功能审计的内容包括： ? 验证当前基线所含配置项对前一基线所含配置项的追溯性； ? 确认当前基线所含配置项均正确反映了项目需求； ? 评估基线的完整性； ? 验证当前基线和各基线间所含配置项的一致性； 验证配置库内容的完备性和正确性等。
软件配置管理报告
份号：001密级: XXXXXXX项目 软件配置管理报告 XXXX-RPB-R01.00 XXXXXXXX 公司 XXXX 年XX月XX日
辑要页
摘要: 主题词:
文档修改记录
1范围............................................................................................... 1.1标识.......................................................................................... 1.2系统概述...................................................................................... 1.3文档概述......................................................................... 1........... 2引用文挡........................................................................................... 3软件配置管理情况综述............................................................................. 4软件配置管理基本信息............................................................................. 5专业组划分及权限分酉己.......................................................................... 6配置项记录......................................................................................... 7变更记录........................................................................................... 8基线记录........................................................................................... 9入库记录...........................................................................................
软件配置管理流程
配置管理流程规定 (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)配置库的日常操作和维护 开发人员
16软件配置管理报告
份号：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 目的..................................................................... 1 1. 2 定义和缩写 词 ............................................................. 1 1.3 参考资 料 ................................................................. 1 2 管 理 ..................................................................... ........ 1 2.1 机
构..................................................................... 1 2. 2 任务..................................................................... 2 2. 3 职责..................................................................... 2 2.4 接口控 制 (2) 2.5 实现..................................................................... 2 2.6 适用的标准、条例和约 定 (3) 2.6.1 指明 (3) 2.6.2 内容................................................................. 3 3 软件配置管理活 动 (4) 3.1 配置标 识 (4) 3.1.1 基线 (4) 3.1.2 代码、文 档 ........................................................... 4 3.2 配置控制 .................................................................
软件项目配置管理系统计划清单指导应用清单
中国核电集团 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默认设置为与域的设置相同。 若个人要求另行设置的，由项目组配置管理员负责汇总后，提交给高级配置管理员调整设置。
(五)配置项计划 填写上面表格过程中，需要对照成果物列表逐项填写。
SCMS软件配置管理过程
C M M文件软件配置管理过程 XXXXXXXXXXXX (版权所有,翻版必究)
文档变更请求(DCR)
文档变更记录
目录 1 概述 (1) 1.1 目的 (1) 1.2 范围 (1) 1.3 术语与定义 (1) 1.4 参考文档 (1) 1.5 引用文档 (2) 2 过程目标 (2) 3 过程定义 (2) 3.1 责任人 (2) 3.2 输入 (3) 3.3 入口准则 (3) 3.4 过程活动 (3) 3.5 出口准则 (6) 3.6 输出 (6) 附录 A ：软件配置项/产品包标识 (8) A.1 文档的编号 (8) A.2 程序的名称 (9) A.3 软件产品包的标识 (9) A.4 系统、数据库、开发与支持软件工具的编号 (9) 附录 B ：配置项状态报告 (10) B.1 系统软件、数据库、开发与支持软件工具列表 (10) B.2 软件基线/配置项状态报告 (10) B.3 软件基线软件基线变更报告 (10) 附录 C ：软件配置管理测量报告 (11)
1概述 1.1目的 软件配置管理（简写为SCM）是维护项目软件整个生命周期产品完整性的重要活动，本文档明确规定了公司软件配置管理活动的目标和过程定义，为公司软件配置管理提供所遵循的过程、程序和指导方针。 1.2范围 本文档适用于管理公司所有软件项目在各阶段标识的软件配置。软件配置管理的大部分活动用“软件配置管理工具”实现。 1.3术语与定义 1.3.1软件工作产品：作为定义、维护或应用软件过程的一部分所生成的任何人工制品，包括过程描述、 计划、规程、计算机程序和相关文档，这些可能交付也可能不交付给顾客或最终用户。 1.3.2软件基线：软件配置项经软件验证、确认、评审和认定后，形成了软件基线，也就成了该阶段的一 个基准。下一个阶段只能在这个基准上进行开发活动。 1.3.3软件配置项：是指一个软件产品在软件生存周期各个阶段所产生或应用的各种形式（机器可读或人 工可读）和各种版本的文档、程序及其数据。 1.3.4SCCB：软件配置管理委员会（Software Configuration Control Board）（关于责任，参见“责任 人”）。 1.3.5SCM：软件配置管理(Software Configuration Management) 包括了标识软件工作产品、控制对 软件工作产品的更改、和维护在整个软件生存周期中的软件工作产品的完整性和可跟踪性。 1.4参考文档 1.4.1Mark C. Paulk，Bill Curtis，Mary Beth Chrissis，Charles V. Weber，Capability Maturity Model for Software （Version 1.1） 1.4.2Roger S. Pressman，Software Engineering –A Practitioner’s Approach (Fourth Edition) 1.4.3《计算机软件配置管理计划规范》GB/T 12505-90
软件配置管理计划示例
软件配置管理计划示例 作者：赵文锋计划名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．各子系统的配置管理人员具体负责实施各自的配置管理工作，并参与各子系统的功能配置检查和物理配置检查；
ISO软件开发全套文档-配置管理计划编写指南
产品/项目系统名称 配置管理计划 北京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．设计文档
配置管理系统
配置管理系统（北大软件 010 - 61137666） 配置管理系统，采用基于构件等先进思想和技术，支持软件全生命周期的资源管理需求，确保软件工作产品的完整性、可追溯性。 配置管理系统支持对软件的配置标识、变更控制、状态纪实、配置审核、产品发布管理等功能，实现核心知识产权的积累和开发成果的复用。 1.1.1 组成结构（北大软件 010 - 61137666） 配置管理系统支持建立和维护三库：开发库、受控库、产品库。 根据企业安全管理策略设定分级控制方式，支持建立多级库，并建立相关控制关系；每级可设置若干个库；配置库可集中部署或分布式部署，即多库可以部署在一台服务器上，也可以部署在单独的多个服务器上。 1. 典型的三库管理，支持独立设置产品库、受控库、开发库，如下图所示。 图表1三库结构 2. 典型的四库管理，支持独立设置部门开发库、部门受控库、所级受控库、所级产品库等，如下图所示。
图表2四级库结构配置管理各库功能描述如下：
以“三库”结构为例，系统覆盖配置管理计划、配置标识、基线建立、入库、产品交付、配置变更、配置审核等环节，其演进及控制关系如下图。 图表3 配置管理工作流程 1.1.2主要特点（北大软件010 - 61137666） 3.独立灵活的多级库配置 支持国军标要求的独立设置产品库、受控库、开发库的要求，满足对配置资源的分级控制要求，支持软件开发库、受控库和产品库三库的独立管理，实现对受控库和产品库的入库、出库、变更控制和版本管理。
系统具有三库无限级联合与分布部署特性，可根据企业管理策略建立多控制级别的配置库，设定每级配置库的数量和上下级库间的控制关系，并支持开发库、受控库和产品库的统一管理。 4.产品生存全过程管理 支持软件配置管理全研发过程的活动和产品控制，即支持“用户严格按照配置管理计划实施配置管理—基于配置库的实际状况客观报告配置状态”的全过程的活动。 5.灵活的流程定制 可根据用户实际情况定制流程及表单。 6.支持线上线下审批方式 支持配置控制表单的网上在线审批（网上流转审批）和网下脱机审批两种工作模式，两种模式可以在同一项目中由配置管理人员根据实际情况灵活选用。 7.文档管理功能 实现软件文档的全生命周期管理，包括创建、审签、归档、发布、打印、作废等，能够按照项目策划的软件文档清单和归档计划实施自动检查，并产生定期报表。 8.丰富的统计查询功能，支持过程的测量和监控 支持相关人员对配置管理状态的查询和追溯。能够为领导层的管理和决策提供准确一致的决策支持信息，包括配置项和基线提交偏差情况、基线状态、一致性关系、产品出入库状况、变更状况、问题追踪、配置记实、配置审核的等重要信息； 9.配置库资源的安全控制 1)系统采用三员管理机制，分权管理系统的用户管理、权限分配、系统操 作日志管理。 2)系统基于角色的授权机制，支持权限最小化的策略； 3)系统可采用多种数据备份机制，提高系统的数据的抗毁性。 10.支持并行开发 系统采用文件共享锁机制实现多人对相同配置资源的并行开发控制。在系统共享文件修改控制机制的基础上，采用三种配置资源锁以实现对并行开发的
软件配置管理流程
软件配置管理流程
目录 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 配置审计 (7) 1.9.1 配置审核的类别 (7) 1.9.2 配置审核执行的时机 (7) 1.9.3 不符合项的处理 (7) 2.0.0 配置状态报告 (7) 2.0.1 配置状态报告的目的 (7) 2.0.2 配置状态报告记录的内容 (7) 2.0.3 配置状态报告的生成 (7) 2.1.0 发行管理 (8) 2.1.1 交付管理 (8) 2.1.1 软件配置管理员的处理规范 (8) 2.1.1.1 现阶段使用的版本配置服务器 (8) 2.1.1.2 主要操作流程 (8) 2.1.1.3 版本规范化处理 (8) 2.1.1.4 客户反馈问题处理 (8) 2.软件基线化规范 (9) 2.1 正常开发期 (9) 2.2 版本发布期 (9) 2.3 项目发布期 (9) 2.4 项目维护期 (9)
1.配置管理流程 概述 规范配置管理活动,明确配置项正确的唯一标识并易于存取,保证基准配置项的更改受控,明确基线状态,在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 总体流程图
软件需求分析阶段 参加需求分析会议,配置管理负责人记录,有关文档提交归档。如《需求分析》。 软件设计阶段 参加涉及阶段,为了详细制定配置管理计划。针对需求分析报告进行系统设计，配置时应说明系统设计的版本于需求分析报告版本的对应关系。设计书评审通过后，建立设计基线。 制定配置管理计划 配置管理员制定配置管理计划,主要内容包括配置管理软硬件资源、配置项计划、备份计划等,审批该计划。 配置库管理 配置管理员为项目创建配置库,并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。 相关人员分配权限 项目经理： 1）与（有关负责人员）协商确定项目起始基线； 2）接受配置管理计划，并按相关规定贯彻执行； 3）接受配置控制委员会的报告； 4）提出配置管理计划的修改要求； 5）提出管理的建议和要求。 配置管理员 1）编制配置管理计划； 2）执行配置项管理； 3）执行版本控制和变更控制方案； 4）编制配置状态报告； 5）配置库的建立和权限分配； 6）配置管理工具的日常管理与维护； 7）配置库的日常操作和维护； 开发人员 1）根据确定的配置管理计划和相关规定，提交配置项
软件配置管理计划模板
卷号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 范围 本文档适用于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. 引言 包括目的、缩写词和参考资料，具体内容略。 2．组织及职责 配置管理的角色和职责见表1。 表1：配置管理角色职责表 3.配置管理环境 由于本项目属于中小型项目，工期也不很长，而且项目组人员对Visual SourceSafe也比较熟悉，所以采用Visual SourceSafe作为配置管理工具。 3.1配置库目录结构
3.2用户及权限 4．配置管理活动 4.1 配置项标志 4.1.1 命名规范 本项目配置项命名规范由5个字段组成，从左到右依次为：公司、项目、类型、编号和版本号，如图1所示。这些字段用一横线（-）分隔。
图1：配置项命名规范 4.1.2 主要配置项 QTD-School –RM –SRS-v1.0 公司：3个字符 项目：最长10个字符 类型：最长5个字符 编号：最长8位数字/字符 版本号：V m.n
4.1.3 项目基线 在Visual SourceSafe中基线由LABLE标志，字母必须为大写。基线管理由项目执行负责人确认、SCCB授权，由配置管理员执行。 表5 4.1.4 配置项的版本管理 配置项可能包含的分支从逻辑上可以划分成4个不同功能的分支：主干分支、私有分支、小组分支、集成分支。让它们分别对应4类工作空间。 这四类工作空间（分支）由项目执行负责人统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。 对配置项的版本管理在不同分支具有不同的策略： （1）主干分支 系统默认自动建立的物理分支——主干分支（/main）,基线均以LABLE方式出现在主干分支上。 （2）私有分支 如果多个开发工程师维护一个配置项时建议建立自己的私有分支。配置管理员对其基本不与管理，如个别私有空间上的版本树过于冗余，将对其冗余版本进行限制。 （3）小组分支 如果出现小组共同开发一配置项，该分支可视为项目组内部分组的私有空间，存放代码开发过程中的版本分支，由项目组内部控制。
软件配置管理规范流程
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 概述 1.1 目的 本文档主要目的在于规范项目配置管理活动, 确保配置项正确地唯一标识而且易于存取, 保证基线配置项的更改受控, 明确基线状态, 在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用范围本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动, 针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法, 本文件以CVS( 并行版本系统) 配置管理工具为例, 规定公司的配置管理办法, 使用其它工具时也可对应本文件
的要求参照执行。 1.3 术语和缩略语 1.3.1 软件配置管理( Software Configuration Management, SCM) 软件配置管理是对软件修改进行标识、组织和控制的技术, 用来协调和控制整个过程。是经过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程, 确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 1.3.2 配置项( Configuration Item, CI) 凡是纳入配置管理范畴的工 作成果统称为配置项, 配置项逻辑上组成软件系统的各组成部分, 一般是能够单独进行设计、实施和测试的。 每个配置项的主要属性有: 名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里, 确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 1.3.3 基线( Baseline) 在配置管理系统中, 基线就是一个配置项或一组配置项在其生命周期的不同时间点上经过正式评审而进入正式受控的一种状态这些配置项构成了一个相对稳定的逻辑实体, 而这个过程被称为基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素( 配置项) 的一个版本, 且只确定一个版本。一般情况下, 基线一般在指定的里程碑处创立, 并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制, 基线中的配置项被冻结”了, 不能再