软件配置管理方法

软件配置管理办法

1软件配置管理基础

1.1软件配置管理简介

随着计算机应用范围的日益广泛，应用软件的规模及复杂度日益广泛深入，应用软件的规模和复杂程度日趋大型化，复杂化，这就导致软件开发的方式越来越强调团队的协作开发。

而在这种开发方式下，会遇到很多问题，例如：需要将整个软件的版本恢复到以前的某一时间的状态，限制随意修改程序，或者控制某一程序在同一时间内只能一个开发人员修改等等。

为了解决这些问题，提高软件产品和软件项目的质量及软件开发过程中的管理水平，更好地为以后的软件开发工作提供有效的服务，必须采用先进的管理手段，实现软件产品和软件项目源码的科学管理。

1.2软件配置管理工具

软件配置管理工具有很多，例如：Starteam、PVCS、ClearCase、VSS和CVS等。Starteam、PVCS和ClearCase更适合庞大的团队和项目，并且价格不菲，所以并不常用。目前使用比较广泛的是VSS和CVS。两者在使用上有各自的优势和不足。

VSS的全名是VisualSourceSafe，是微软公司开发的VisualStudio开发套件中的软件配置管理部分，有非常好的技术支持和非常详尽的技术文挡。VSS适合在局域网范围内，以Windows平台为主的中、小项目，以文件管理为主要功能，使用方便，学习成本低，对服务器仅需要快速大容量的存储器也是它的优势。

CVS的全名是ConcurrentV ersionSystem，是一种可以并发的版本控制系统。它是一个开源项目，可以直接从网站下载最新的源代码。CVS可以满足局域网和广域网不同的网络条件，提供不同级别安全性选择，在一台专门的服务器配合下，客户可以使用任何平台开发项目。CVS本身是在unix系统上开发的，在unix下提供的是命令行使用模式。在Windows 平台下你可以选择用CVSNT搭建服务器，用WinCvs作为客户端。CVS对于已经完成了开发过程进入项目维护阶段，或者进入项目升级阶段的项目，可提供完善的软件配置管理的支持，不过在学习和操作上学习成本比较高。

1.3软件配置管理实施环境

软件配置管理的实施环境由服务器和客户端软件组成，他们的基本功能如下：

1.3.1软件配置服务器

1)集中存放软件产品的文件，供多人访问以便进行协同开发。

2)对产品文件进行安全管理，分配账号并进行访问权限设置。

3)记录所有文件的历史变化，以进行版本控制。

4)保障文件的数据安全，进行冗余存储和备份。

1.3.2客户端软件

1)安装于开发人员的电脑上，用以访问软件配置服务器。

2)提供导入/导出产品模块的功能。

3)提供对文件的检入/检出操作。

4)提供查阅和管理文件历史版本的操作。

2软件配置管理的实施目标

软件配置管理包括的范围比较广，我们当前的目标是：

（1）软件配置管理活动被定义和计划。

（2）软件开发过程中的软件制品（程序源码，文档，数据资料等）被识别、控制和管理。（3）对于处于配置管理下的软件制品的修改被控制。

（4）与软件制品相关的项目组和成员应该被通知制品的目前状态和被修改的信息。

3人员角色分配与职责范围

3.1软件配置管理员

软件配置管理员主要负责如下工作：

1)管理软件配置服务器，维护源码库结构、安全设置，定期备份源码库。

2)编写和维护软件配置管理的相关文档资料，包括服务器配置管理方法、软件配置工

具使用方法、软件配置规则与实行方法等。

3)编写培训材料，制定培训计划，对开发人员和产品管理人员进行培训。

4)为开发人员和产品管理人员提供软件配置工具的高级使用技巧支持。

5)督促开发人员定时提交或更新软件源码及文档资料，确保软件配置规则的实行。

3.2开发负责人

开发负责人主要负责如下工作：

1)管理项目文件夹结构，构建代码框架，导入软件配置服务器。

2)在配置管理员的协助下，对项目文件夹的结构和权限进行管理。

3)根据项目进展制定开发基线，管理软件版本编号以及分支版本，必要的时候，负责

版本的合并，并解决或指导开发人员解决合并冲突。

4)负责软件发布版本的导出，提供给项目实施人员安装使用。

3.3开发人员

开发人员主要负责如下工作：

1)按照开发负责人的任务分配，从服务器导出项目，进行分工协同开发。

2)从服务器获取代码库最新变更，在自己负责的模块中加入、修改或删除文件。

3)及时提交自己的修改到服务器，并附加变更说明。

深圳市友邻通讯设备有限公司

4软件配置管理规则

本规则仅限于软件配置管理，而不涉及软件开发的项目管理过程。

4.1分为开发库和产品库进行管理

在软件配置管理工具中，对于源代码的管理一般分为产品库和开发库进行管理。

在软件配置服务器端分别建立产品库和开发库，产品库用于存放通过编译，形成了一定产品功能并且能够实施的所有软件源代码版本。开发库中存放正在开发过程中的软件源代码，当这些软件源码符合了一定的条件后，将被导入到产品库。同样，当开发库需要产品库的源码做为新的开发基线，产品库的源码也可以被导出到开发库进行重新开发。

产品库用于存放软件产品的一系列可发布版本，包括源代码、设计文档、可执行文件、安装包和产品手册。

开发库用于存放开发过程中的一系列软代码版本，是协同开发的工作目录，管理代码文件的历史变更。

在开发库中开发成熟，通过测试后的软件，经过整理设计文档、产品手册、制作安装包后，导入到产品库中存放。

要对现有软件的某一版本进行改进升级时，从产品库导入开发库，作为本次开发计划的开发基线。

4.2对开发库和产品库的管理和操作

我们根据对软件配置管理的不同角色所分配的不同职责范围，对开发库和产品库进行管理和操作。

4.2.1新建版本库

这是我们进行软件配置管理的第一步。首先，由软件配置管理员在服务器端安装和配置好软件配置管理的工具，然后在服务器上新建两个库目录：产品库和开发库。

4.2.2对开发库的管理和操作

开发库由开发负责人负责日常的更新保管。对开发库的管理操作方法如下：

（1）导入新项目

对于一个新的开发项目，由开发负责人负责构建项目结构。软件配置管理员配合软件开发负责人import（导入）该项目到开发库中并完成对新项目的访问权限设置。

（2）对库文件的导入、导出更新以及修改操作

开发负责人根据开发任务和开发需要分配开发模块给开发人员。

在开发过程中，软件开发人员根据各人对不同模块拥有的不同权限对开发库中相应的文件进行commit（导入）/update（更新），add（增加）/remove（删除）等操作。

软件开发人员要编辑自己的开发模块，首先，必须checkout（导出）该模块到本地，然后在本地对文件进行修改，修改完成后执行commit（导入）命令将该文件导入到开发库中。如果是在模块里面增加文件，那么首先要该文件放在要增加文件的模块中，执行add（增加）

操作。然后执行commit（导入）操作，就完成了在模块中增加文件的操作。如果要从库中删除一个不需要的文件，可以先执行remove命令，然后执行commit操作向开发库中提交。软件开发人员如果要在自己开发的模块里面增加一个目录层，就需要执行import操作。如果一个模块对某个软件开发人员只开放了读权限，那么该软件开发人员只能对这个模块执行update（更新）操作。

建议开发人员每天早上对开发模块使用update（更新）命令做更新操作，下午下班之前对开发模块执行commit（提交）命令，以避免冲突和丢失修改。同时，程序员必须保证上传的代码是通过编译的源代码。

对于涉及更改项目结构的操作，应由开发负责人负责执行。

（3）对项目进行分支和标记标签

在开发过程中，很多时候需要对一个项目进行branch（分支）操作，在分支上对项目进行开发。这由软件开发人员负责执行。

当项目开发到一个特定阶段，由开发负责人为软件打上标记标签（tag），作为一个项目开发的里程碑或开发基线。

（4）再次分配开发模块

开发负责人根据开发任务和开发需要分配开发模块给开发人员。负责一个开发模块的开发人员我们称为该模块的模块负责人。

在开发过程中，模块负责人可以根据需要把一个开发模块分成几个小的开发模块分配给其它的开发人员进行开发，软件配置管理员配合模块负责人对这些小模块进行访问权限的设置。之后，各开发人员就可以根据给各人所分配的权限checkout（导出）这些小模块进行开发。

（5）上传开发完成的项目到产品库

一个软件项目开发完成之后，由软件开发负责人从开发库中导出不包含版本控制信息的该项目的所有模块并把它import（导入）到产品库中。同时，由软件配置管理员负责监督检查这些上传的项目模块是否符合软件结构和配置管理规范等。

至此就完成了对一个新项目的开发管理过程。

4.2.3对产品库的管理和操作

产品库由软件配置管理人员保管。产品库中的软件源代码版本来源于开发库或者是公司以前旧的软件产品版本。

对于一个已经开发完成的软件产品，在在投入使用一段时间之后，可能要面临版本升级的情况，例如：在使用过程中可能会发现该软件的当前版本存在bug，对于少量的bug，我们可以在软件原版本上进行修改。但是当bug累计到一定的阶段，我们对原版本的修改越来越多时，就要考虑在原版本的基础上进行版本的升级。

在软件产品的现有版本上进行版本的升级，首先由软件开发负责人负责checkout(导出)该软件（在导出的时候不要导出版本控制文件夹）到本地，然后import（导入）该软件到开发库中。之后，软件开发负责人和软件开发人员就可以按照对开发库的管理和操作方法根据

深圳市友邻通讯设备有限公司

需要对项目进行修改或者再次开发。

产品的版本号由开发负责人指定。开发负责人对产品库中的所有版本功能特性的变更要有一个完整的说明，便于以后的开发和使用。这些工作由软件配置管理人员监督执行，确保软件产品的完整性和正确性。

4.3各司其职以免扰乱版本库结构

软件配置管理员，开发负责人和开发人员要根据自己的职责范围做好工作，以免扰乱版本库结构。

5软件配置管理的方法和技巧

5.1版本主线和分支的概念及运用

5.1.1版本主线

我们把一个项目的主要开发过程成为开发主线。通常，一个文件的主干版本历史是一条增长线。

5.1.2分支

软件配置管理并不局限于线性的开发。它可以将对文件的修改隔离到一个分离的开发线上，而不会影响主线版本，这条线被称为分支。

（1）主线版本可以分为不同的分支，每一个分支可以是一个独立的自我维护的开发线。当你改变了一个分支中的文件时，这些更改不会出现在版本主线和其它分支版本中。如果有需要，你可以使用merge（合并）命令将这些变更合并到另一个分支或者版本主线上。

（2）在软件配置管理中进行branch（分支）操作，一般是针对整个软件项目：编译好的.exe、.dll文件等。对一个或者几个文件进行分支操作是没有实际意义的。

（3）软件项目开发过程中充满了各种不确定性，有时我们需要试探，那么我们在主线版本上开发就存在一定的风险，可能会破坏原来的版本结构。而使用分支可以帮我们解决这些问题。例如：当软件已经达到了一个相对稳定的状态，下一步是想实验加入一种新功能（新算法），但是对它没有信心。担心加入新内容后，系统边的不稳定，希望能方便地回到目前的稳定状态。再比如：我们已经发布了一个软件的1.0版本，目前的工作已经集中在版本2.0。但是，这时发现版本1.0有一个严重的bug。那么，这些情况下，最好的方法就是使用分支。

5.2开发基线和里程碑

在软件配置管理中，开发基线和里程碑是两个重要的概念。

（1）里程碑：项目开发到一定的阶段，例如：新上传了一个模块、编译通过了一个模块、完成了一定的产品功能等，都可以给该项目设定一个阶段的里程碑。对于里程碑的设定，可以是一个项目，也可以是几个文件。在我们的开发过程中，一般是对整个项目设定里程碑。里程碑也是项目多个分支开发的基础。

（2）开发基线：对实现了一定功能的软件产品打上tag标记作为一个开发基线（baseline）。一个开发基线是一个特殊的里程碑，开发基线作为一个再次开发的基础。例如：开发一个软件，初步实现了产品要求的大的功能框架，那么这时候我们可以为该软件打上tag标记作为一个开发基线，作为其它补充功能开发的基础。同样，在开发过程中，对开发基线的设定也是针对整个项目。

（3）设定里程碑和开发基线的tag标志时，要注意给定不同的命名规则，以免在使用过程造成混乱。

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

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

目录 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、软件配置遵循安全性、适用性、 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、."，然后在新的目录中进行修改； 但是这种方法，不仅十分繁琐，容易出错，而且会带来大量的垃圾数据。如果是团队协同开发或者是项目规模较大时，还是会造成很大的混乱。很显然，这样简陋的方法是无法应对这一问题的。后来，有人尝试从制造工业领域引入了"配置管理"这一概念，通过不懈的研究与实践，最终形成了一套管理办法和活动原则，这也就是软件配置管理。 通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报。 常见的配置管理工具 正如前面所述，由于软件配置管理过程十分繁杂，管理对象错综复杂，如果是采用人工的办法不仅费时费力，还容易出错，产生大量的废品。因此，引入一些自动化工具是十分有裨益的，这也是做好配置管理的必要条件。 正是因为如此，市场上出现了大量的自动化配置管理工具，这些工具的实现原理与基本机制

软件配置管理流程

配置管理流程规定 (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 配置项记录 本章所列出项目的所有配置项，包括配置项名称、配置项最后发布日期、配置项控制力度(控制力度可分为基线管理、非基线管理(受到管理和控制))、配置项版本变更历史、配置项变更累计次数等内容。

办公资源配置管理办法

办公资源配置管理办法 第一章总则 第一条为规范公司本部办公资源配置管理，提高公司办公资源配置效率，制定本办法。 第二条本办法适用于国华电力公司本部。 第三条本办法所称办公资源主要指公司为员工开展工作所配备的办公用品、办公设备、办公家具及行政办公应用系统资源。 第二章办公资源配置标准 第四条办公设备配置标准 注：各部门有多个办公室且相隔较远的，可单独配备打印机。 第五条办公家具配置标准

第六条行政办公应用系统配置标准 第七条办公用品配置标准 （一）一般岗位个人办公用品配置范围：文件夹、资料册、资料盒、U盘、移动硬盘、刻录盘、鼠标、鼠标垫、个人专用计算器等。 （二）部门公共办公用品配置范围：签字笔、自动铅笔、铅笔芯、铅笔、荧光笔、白板笔、直尺、橡皮、笔记本、信封、信纸、便签纸、复写纸、口取纸、N次贴、剪刀、裁纸刀、切纸刀、订书机、订书钉、推夹器、推夹器用夹、订夹扣、回形针、图钉、大头针、胶棒、涂改液、透明胶带、胶带座、双面胶、印泥、印油、长尾夹、橡皮筋、打孔机、计算器等。 （三）公司副总师以上领导办公用品根据实际需要配置。

第八条特殊岗位根据实际工作需要配置办公资源。 第三章办公资源配置办法 第九条本部办公用品实行定额管理，定额内根据工作需要领用。 （一）个人办公用品定额：部门经理以上80元/月，员工60元/月。 （二）部门公共办公用品定额：按照各办公室人员核定，20元/人月。 （三）复印纸、墨盒、硒鼓、碳粉等耗材按设备核定费用定额（不含楼层公共文印区设备）。定额内按实际消耗领用，超出定额需经总经理工作部审核，主管领导审批。 第十条办公设备中打复印、传真设备、扫描仪、固定电话、饮水机、碎纸机等由公司按标准统一配置，手机和笔记本电脑按以下办法配置。 （一）手机配置 1、公司副总师以上领导根据实际需要配置。 2、其他公司正式员工实行“公司定额补贴，员工自行购机”的形式配备。 3、购机补贴标准为1000元/人·年，首次购机另补1000元/人。

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

软件配置管理规范.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.配置管理流程 (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）根据确定的配置管理计划和相关规定，提交配置项

软件配置管理计划示例

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

资源配置管理制度

资源配置管理制度 （试行） WHNYLM/ZD-059-2015 第一条总则 为规范资源配置管理，提高管理效率，依据神华集团《煤化工企业安全风险预控管理体系要求》及《能源公司资源配置管理制度》及乌海能源公司的相关规定，制定本制度。 本制度所指的资源是为确保企业推进安全风险预控管理体系而配备的各项人力、财力、基础设施、技术、信息等资源。 资源的配置要符合国家法律、法规、标准及集团公司、能源公司的相关规定；符合各单位性质、规模、发展规划及风险控制的需要；符合各级管理者、企业员工及相关方的需求。 本制度适用于公司各生产单位及部室。 第二条组织及职责 各单位主要负责人全面负责本单位资源配置管理，并任命安全生产分管领导，具体主抓资源配置工作。应为本质安全管理体系的有效运行提供必要的人力、财力、物力、技术、信息资源。 第三条相关部门履行以下资源配置职责： （一）安健环部负责体系建立、实施、保持及持续改进的牵头、组织、协调、监督、考核等工作。 （二）财务部门负责体系运行所需资金的投入。 （三）经营管理部负责人力资源管理。 （四）生产技术部门负责技术资源管理。

（五）机电动力部门负责基础设施管理。 （六）其他各职能部门负责相应业务范围内的资源配置管理。 第四条资源配置的原则 人力资源配置应当做到人尽其才，才尽其用，人事相宜，最大限度地发挥人力资源的作用。 设备设施配置应当做到科学合理，优化结构，勤俭节约，从严控制。对有规定配备标准的设备设施，应当按照标准进行配备；对没有规定配备标准的设备设施，应当从实际需要出发，从严控制，合理配备。 资金的配置应遵循安全性、可用性、效率性原则。 第五条资源配置的要求 人力资源的配置要求按岗位所需配置，并确保人员能力和相应的培训； 设备设施的配置应满足企业的生产、发展及本体系的有效实施，并确保设备设施的完整性。 体系运行过程中所需的资金必须及时上报计划，有效投入使用。 技术、信息的配置符合企业发展的要求，鼓励技术创新，信息共享。 第六条各单位的资源配置按如下程序开展： （一）对业务范围内的资源配置资金需求提出计划（应在上一年度末编制下一年度的资源配置需求计划）。人力资源计划报经营管理部，设备设施计划报机电动力部，信息耗材报生产信息部，资金需求计划报核算中心。 （二）对提出的资源配置需求计划，依据业务管理归口报领导逐级审批。 （三）实施已审批的资源配置需求计划，并在实施过程中开展监督、

软件配置管理控制程序A0

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

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

软件配置管理规定

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

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

人力资源配置和管理程序

发行版本：A 修改码：0 人力资源控制程序 文件编码：XX/Q6201 页码：1/4 ————————————————————————————— XX 股份有限公司程序文件 1、 目的 为做到企业合理用人,发挥员工能量的重大化，建造高素质的员工队伍，确保公司各类人员的专业素质和业务技能不断提高，以保证在企业经营中持续提高顾客满意度，特制定本程序。 2、范围 本程序适用于公司所有与质量有关的职工和干部，包括新员工临时工和最高管理层。 2、 范围 本程序适用于公司所有与质量有关的职工和干部，包括新员工临时工和最高管理层。 3、 术语 3.1 人力资源：是质量管理体系的主要资源，在本程序中可理解为对所承担确保产品质量能力人员的甄选，或者所具备程序中某项专业技能和才干的人员。 3.2人力资源管理：人员的调配，员工素质的要求和管理，人力招聘、录用，人力资源培训与开发、薪金体系管理的资格评定等相关内容。 4、 职责 4.1 总经办是人力资源管理的负责部门，负责公司的人力资源配置、管理、开发、激励。 4.2 各部门根据生产及工作需要提出对人力资源的配置需求，人事部负责 人员招聘和甄选面试等工作。 4.3 人事部是培训的主要负责部门归口为总经办

5、工作程序 5.1人员调配 5.1.1公司各部门根据工作和生产的实际需要提出人员需求的申请上报总 经办。 5.1.2总经办根据各部门的需求的实际确定岗位人选的能力要求，后上报给 主管总经理批准后实施。 5.1.3确定适应岗位的职责能力的标准，应为熟悉该岗位职责或熟练掌握该 专业业务的人选。人事部门应多渠道、多方面对人选进行选择招聘，最后确定适合人选。 5.1.4为了使员工迅速进入角色，人事部门应对新聘任人员组织岗前、岗中 和持续能力培训，从而达到公司不断的需求。 5.1.5在人员配置过程中，总经办对调配人员的受教育水平培训经历、技能 和相关工作经验做综合分析，以保证从事影响产品质量的所有人员都能胜任其工作。同时，人事部门应保存其相关资料记录。 6、培训 人事部门对公司的员工有组织培训提出专业及相关业务技能的职责。 6.1 培训管理流程 人事部门根据年初工作计划制定年度培训工作计划，各部门参照年度培训计划制定本部门的培训计划，同时上报总经办备存。 6.2 人事部门根据年度培训计划下发给各部门培训需求表征求各部门的需求意见后作为参照，制定当月公司培训计划。 6.3 各部门参照公司月度培训计划制定本部门培训计划。同时月底前将部门培训情况即验证记录和培训记录上报人事部。 6.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） 在配置管理系统中，基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，这些配置项构成了一个相对稳定的逻辑实体，而这个过程被称为“基线化”。每一

软件配置管理规范标准

页眉 软件配置管理规范 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 适用范围本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动, 针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法, 本文件以CVS( 并行版本系统) 配置管理工具为例, 规定公司的配置管理办法, 使用其它工具时也可对应本文件

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

06-资源配置管理程序

资源配置管理程序 1 目的与范围 为了合理配置体系运行所需人力、物力和财力资源，特制定本程序。 本程序规定了公司职业健康、安全、环境资源配置的范围、依据、原则、计划编制和审批等管理内容。 本程序适用于公司职业健康、安全、环境资源配置管理。 2 职责和权限 2.1最高管理者保证为建立、实施、保持和持续改进健康、安全与环境管理体系提供必要的资源。 2.2人事劳资管理部负责人员、机构、能力、意识和培训的管理。 2.3生产安全部负责： ——基础设施、生产设备、生产物资管理。 ——设施完整性、工作环境、安全设施与装备管理。 2.4技术开发部负责为职业健康、安全、环境管理提供技术支持。 2.5财务资产部负责各种资源计划、HSE措施费用、资金管理。 3 程序内容 3.1资源配置的范围： ——人力资源； ——物力资源； ——财力资源； ——技术资源； ——专项技能； ——基础设施等。 3.2资源配置依据 3.2.1职业健康、安全、环境法律、法规及其他要求。 3.2.2公司职业健康、安全、环境方针、目标。 3.2.3公司中、长期发展规划及可持续发展战略。 3.2.3公司职业健康、安全、环境活动中风险削减及应急需要。 3.2.3管理评审的建议整改。 3.2.3公司各级管理者、员工及相关方意见。 3.2.3满足合同要求所必须的设施条件。 3.3资源配置计划的原则 3.3.1最大限度的满足公司生产经营及职业健康、安全、环境目标的实现； 3.3.2依靠技术，人尽其才，物尽其用，最大限度地挖掘各种资源的潜力； 3.3.3合理开发、优化组合，最大限度地发挥各种资源的综合效益； 3.3.4节约资源。 3.4资源配置计划的编制和审批 3.4.1各单位根据职业健康、安全、环境方针目标，于每年四季度提出下年度职业健康、安全、环境