配置管理控制程序
配置管理控制程序
1 目的及范围
1.1 为确保公司研制或生产的产品或配件在整个生命周期内数据的完整性、正确性和可追溯性，特制订本程序。
1.2 本程序规定了配置管理的职责、内容和要求。
1.3 本文件适合公司研制或生产产品或配件的配置管理。
2 术语定义
GB/T 19000和IRIS界定的术语和定义适用于本文件。
2.1 技术状态：在技术文件中规定的并且在产品中所达到的产品功能特性和物理特性。
2.2 功能特性：产品的性能指标和设计约束条件。
2.3 物理特性：产品的形体特征，如尺寸参数、表面状态、形位公差、质量等，又称实体特性。
2.4 配置管理：又称技术状态管理，指运用技术的和管理的手段对产品技术状态进行标识、控制、审核和记实的活动。包含技术状态标识、技术状态控制、技术状态记实和技术状态审核。
2.5 技术状态文件：确定技术状态项的要求、设计、建造/生产、验证和维修所必需的文件。
2.6 技术状态标识：确定产品结构，选择技术状态项，将技术状态项的物理特性和功能特性以及接口和随后的更改形成文件，为技术状态项及相应的文件分配标识符或编码的活动。
2.7 技术状态控制：在技术状态文件正式确立后，为控制技术状态项的更改进行的活动。
2.8 技术状态审核：为确定技术状态项符合其技术状态文件而进行的检查。
2.9 技术状态记实：对所建立的技术状态文件、建议的更改情况和已批准的更改的实施情况所做的正式记录和报告。
2.10 配置管理部件清单：某种型号的产品或者是某批次同型号的产品，需要进行配置管理的零部件、元器件汇总表。简称配置清单。
2.11 产品制造过程：产品从物料采购、开始投产到交付用户的过程。
2.12 产品运行过程：产品从交付用户到质量保证期（或三包期）结束的过程。
3 职责
3.1 产品研究所负责配置管理计划和配置清单编制、提交评审、更改、归档，负责将产品设计相关的配置数据的录入、更改控制与记实，参与对配置清单状态、实物数据状态及数据与产品实物符合性审核。
3.2 技术管理部负责产品配置管理计划、配置清单的评审组织，监督评审意见的落实，负责国内产品配置管理过程监督、检查工作，定期组织各相关部门对配置清单状态、实物数据状态及数据与产品实物符合性审核。
3.3 项目管理部负责出口产品配置管理过程监督、检查工作，定期组织各相关部门对配置清单状态、实物数据状态及数据与产品实物符合性审核。
3.4工艺研究所负责协助提出配置清单中的零部件或元器件（主要是可维修性差或维修时间长的零部件或元器件）信息，负责按《标识和可追溯性控制程序》制订配置清单中零部件或元器件的标识、可追溯方法，参与配置清单的评审，参与对配置清单状态、实物数据状态及数据与产品实物符合性审核。
3.5 生产运营部协助提出配置清单中的零部件或元器件（主要是采购周期长、占用资金多的零部件或元器件）信息，负责外购组件中包含的零部件的配置数据的录入，参与配置清单的评审，参与对配置清单
状态、实物数据状态及数据与产品实物符合性审核。
3.6 生产相关单位负责产品制造过程中零部件配置数据的录入（如产品编号等），参与配置清单的评审，参与对配置清单状态、实物数据状态及数据与产品实物符合性审核。
3.7 质量检验处负责产品制造过程中相关配置数据的汇总、录入与确认（主要是质量记录）。
3.8 售后服务部负责协助提出配置清单中的零部件或元器件（主要是产品以往的应用过程中，经常发生故障或属于惯性质量问题的零部件或元器件）信息，负责国内产品在运行过程中零部件配置数据的录入，参与配置清单的评审，参与对配置清单状态、实物数据状态及数据与产品实物符合性审核。
3.9 国际贸易部负责协助提出配置清单中的零部件或元器件（主要是采购周期长、占用资金多的零部件或元器件以及产品以往的应用过程中，经常发生故障或属于惯性质量问题的零部件或元器件以及用户点装的零部件或元器件）信息，负责与用户就出口产品的配置清单进行沟通，负责出口产品在运行过程中零部件配置数据的录入，参与配置清单的评审，参与对配置清单状态、实物数据状态及数据与产品实物符合性审核。
3.10 市场营销部负责协助提出配置清单中的零部件或元器件（用户点装的零部件或元器件）信息，负责与用户就国内产品的配置清单进行沟通，参与配置清单的评审，参与对配置清单状态、实物数据状态及数据与产品实物符合性审核。
3.11 信息管理部负责配置数据库的维护、技术支持及数据的备份。
5 配置管理项目的程序内容
5.1 配置管理流程图
5.2 配置管理计划的制订
产品研究所根据项目策划、合同等要求编制配置管理计划。配置管理计划用于指导该项目的配置管理工作。配置管理计划在产品设计策划阶段作为《设计和开发计划书》的附件输出。
配置管理计划至少应包括以下内容：
a) 配置管理的目的和范围；
b) 所适用的产品和选择配置实体的标准或原则；
c) 配置管理和相关管理活动实施方面的方针；
d) 相关方的组织、职责和权限；
e) 配置管理活动时间、进度指南；
f) 配置管理工具（如信息技术）的描述。
5.3 配置清单
5.3.1 配置项目的选择原则
一般情况下，可将下述项目选为配置管理项目：
a）法律法规要求；
b）与用户签订的合同中，用户要求关注的零部件或元器件；
c）用户点装的零部件或元器件；
d）设计输出文件中规定的质量重要度为关键特性和重要特性的零
部件或元器件；
e）由设计FME(C)A和过程FME(C)A得出结论零部件或元器件一旦发生故障，对产品运行产生的严酷度等级为严重的或灾难的零部件或元器件；
f）产品以往的应用过程中，经常发生故障或属于惯性质量的零部件或元器件；
g）新的或改进后的具有安全功能的零部件或元器件；
h）采购周期长、占用资金多的零部件或元器件；
i）可维修性差或维修时间长的零部件或元器件；
5.3.2 产品研究所依据配置项目编制原则或合同或项目对配置管理的要求，协同相关部门编制配置清单。配置清单的信息原则上应该保证所列出的零部件或元器件，在实物数据记录时，能够唯一确定所采用的零部件或元器件是符合要求的。至少应包含零部件或元器件名称、型号/图号、适用车型(如果是车组)、生产厂家等信息。
5.3.3 配置清单应单独编号。
5.3.4 配置清单应按《产品设计评审细则》相关规定进行评审。
5.3.5 配置清单需用户同意时，由用户对配置清单进行确认。用户确认可替代本文件5.3.4要求的评审。
5.3.6 配置清单用于指导后续的实物数据的收集。
5.4 配置清单的数据收集与更新
配置管理的实物数据收集包含产品制造过程中的数据收集和产品运行过程中的数据收集，采用数据库对实物数据进行收集。如有可能，配置管理数据应尽可能地延续到产品的生命周期结束。
配置管理的实物数据除去记录配置清单要求的数据外，还应该保证实物的可追溯性，如要求纳入配置管理的零部件或元器件均应有序列号。
为确保在制造和运行中保持其可追溯性，配置管理活动所形成的
文件按谁形成谁保管原则妥善保管，具体按《文件控制程序》执行。
5.4.1 配置清单的数据收集、录入
产品研究所负责配置管理项目中设计相关数据的录入、更改的记实以及配置清单的归口管理。
工艺研究所负责配置管理项目中工艺相关数据录入、更改的记实。
生产运营部负责国内配置管理项目中物料代用、供应商变更的记实。
国际贸易部负责国外配置管理项目中物料代用、供应商变更的记实。对国外产品运行过程中由顾客本身对产品配置进行的更改，及由于各种维修、质量改进等活动造成产品安装零部件或元器件的更改，负责该类数据的采集，及时将更改数据录入到数据库。
售后服务部对国内产品运行过程由顾客本身对产品配置进行的更改，及由于各种维修、质量改进等活动造成产品安装零部件或元器件的更改，负责该类数据的采集，及时将更改数据录入到数据库。
生产相关部门：负责生产过程中配置管理项目数据的采集、录入，配置数据随着工序进行流转。
质量检查处：负责配置管理项目制造过程中配置数据的汇总以及确认（主要是质量记录）。
5.4.2 数据管理
5.4.2.1 各相关部门依据自身配置管理职责将配置相关数据录入到PDM，并做到及时更新。应保证数据信息与产品的一致性，确保对整个产品从制造、运行直至生命结束全过程的可追溯。
5.4.2.2 信息管理部门应及时对PDM配置管理数据进行备份，以免发生丢失。
5.4.2.3 技术管理部或项目管理部负责配置管理监督、检查。
5.5 更改管理
5.5.1 配置清单更改
5.5.1.1 配置清单更改
a)设计更改：设计更改如涉及配置清单中所列零部件或元器件，需在更改中特别说明，然后对配置清单进行相应的更改。
b)非设计更改：产品在制造、调试、运行过程中，对零部件或元器件进行了个别更改或批量更改，如涉及到配置清单所列零部件或元器件，需在更改中特别说明，并抄送产品研究所，然后对配置清单进行相应的更改。
5.5.1.2 配置清单的更改按《变更控制管理程序》的相关规定进行，并按本文件5.3.4～5.3.5的要求进行评审或与用户沟通。
5.5.2 实物数据更改
5.5.2.1 配置清单更改完成后，产品研究所应组织实施更改后的配置数据录入数据库。
5.5.2.2 产品在制造、调试、运行过程中，对零部件或元器件进行了个别更改，如涉及到配置清单所列零部件或元器件，应在更改中特别说明，并抄送产品研究所。同时由更改实施部门收集数据并录入数据库。
5.6 其它配置信息
有关配置信息的其它信息，如技术要求、规范、设计图样、部件清单、测试要求、维护和操作手册等，其管理按《文件控制程序》要求执行。
5.7 数据审核和状态说明报告
5.7.1 技术管理部或项目管理部应定期组织各有关部门，对配置清单状态、实物数据状态及数据与产品实物符合性进行审核。
5.7.2 技术管理部或项目管理部应根据审核情况编制状态说明报告，对决策和设计改进提供信息。状态说明报告至少应包含以下内容：
a) 交付的文件，指出相关修改信息；
b) 产品目前的状态，包括已执行、正在进行和准备执行的状态信息；
c) 影响RAMS要求的问题通报；
d) 解决问题的建议。
5.7.3 各相关部门根据状态说明报告及时纠正问题。
6 相关程序文件和记录
6.1相关程序
6.1.1标识和可追溯性控制程序
6.1.2 产品设计评审实施细则
6.1.3变更管理控制程序
6.1.4文件控制程序
6.2记录
6.2.1 配置清单
7 本程序更改记录表
公司技术文件
XXXXXXXXXXXX
配置管理计划
拟制:XXX 审核:XXX
批准:XXX
公司
二〇一三年〇三月
XXXXXXXX配置管理计划
1前言
根据IRIS标准和客户要求，对XXXXXXXX进行配置管理。本配置管理从计划下发日开始实施。
2引用文件
《变更管理控制程序》
《配置管理控制程序》
《标识及可追溯性控制程序》
……
3职责
项目管理部：XXXXXXX。
技术管理部：XXXXXXX。
产品研究所：XXXXXXX。
工艺研究所：XXXXXXX 。
生产运营部：XXXXXXX。
国际贸易部：XXXXXXX。
质量检查处：XXXXXXX。
……
4配置管理计划的制订
5配置管理项目选择的原则……
6配置清单的编制
……
7配置清单数据的录入……
8配置清单的更改
……
9数据审核和状态说明……
11
软件配置管理流程
配置管理流程规定 (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)配置库的日常操作和维护 开发人员
软件配置管理过程指导说明书(超级实用)
软件配置管理过程指导说明书
目录 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）。 配置审计：可以分为物理审计和功能审计。物理审计审查配置项的外在特征的正确性与一致性，主要考查软件受控库的结构、内容及其它相关信息，以验证基线和描述它的文档的一致性；功能审计审查配置项内容的正确性与一致性，主要考核配置项在实现功能上的一致性，功能审计主要通过评审和测试报告体现。 物理审计的内容包括： ? 确认配置项标识的正确性； ? 确认已受控配置项的更改是受到控制的； ? 验证配置库内容与相应记录之间的一致性； ? 验证配置管理活动与相应记录之间的一致性； ? 验证配置管理工作是否符合适用的标准和规程； ? 验证配置管理系统与系统备份的有效性、一致性等。 功能审计的内容包括： ? 验证当前基线所含配置项对前一基线所含配置项的追溯性； ? 确认当前基线所含配置项均正确反映了项目需求； ? 评估基线的完整性； ? 验证当前基线和各基线间所含配置项的一致性； 验证配置库内容的完备性和正确性等。
配置管理流程
配置管理流程 Company Document number：WUUT-WUUY-WBBGB-BWYTT-1982GT
简介 业务目的： 为解决、控制过程及部分服务交付过程提供需要的配置项及其属性信息。 IT 目的： 1)建立一个完整的配置项管理框架，降低了无控制环境变更的危险性； 2)CMDB提高支援及各类服务活动的效率和品质，确保服务交付流程如连续性、容量等良好运作。 适用范围 此流程适用IT管理手册中定义的服务范围。 相关流程 IT服务管理手册 (QM-ITSM-2011) 服务规划及管理流程(OP-ITSM-004) 服务报告管理流程 (OP-ITSM-006) 事件和服务请求管理流程 (OP-ITSM-007) 问题管理流程 (OP-ITSM-008) 变更管理流程 (OP-ITSM-010) 发布管理流程 (OP-ITSM-011) 连续性管理流程 (OP-ITSM-012) 容量与可用性管理流程 (OP-ITSM-014) 信息安全管理流程 (OP-ITSM-015) 供应商管理流程 (OP-ITSM-017) 服务策划管理流程(OP-ITSM-019) 定义 术语表： 无 角色定义表
仪器种类代号
编号格式 主要设备按以下方式进行编号登记： XX9999YY XX = 仪器种类代号 9999 = 4至5位数字 YY = 地域代号内的缩写式代号 内容 流程解释 配置管理流程从配置规划、日常运维、配置审计、配置管理检讨的PDCA循环保障CI的完整性和有效性，其中配置规划包括配置管理应用的各类规则。 配置规划 (P) 5.2.1配置管理范围工具、用途说明：
软件开发项目配置管理工具的选择
软件开发项目配置管理工具的选择 通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报…… 每一个软件项目，无论是工程类项目，还是产品类项目，都必须经历需求分析、系统设计、编码实现、集成测试、部署、交付、维护和支持的过程。在这个过程中，将生成各种各样不同的工件，包括文档、源程序、可执行代码、支持库。更可怕的是，频繁出现的变更是不可避免的，因此面向如此庞大且不断变动的信息集，如何使其有序、高效地存放、查找和利用就成为了一个突出的问题。 针对这一问题，最早的开发人员尝试过的解决办法是通过手工来实现： 1)文档：每次修改时都另存为一个新的文件，然后通过文件名进行区分，例如"XXX 软件需求说明书V1.0，XXX软件需求说明书V1.1，XXX 软件需求说明书V2.0."，并且在文件中注明每次版本变化的内容； 2) 源代码：每次要修改时就将整个工程目录复制一份，将原来的文件夹进行改名，例如"XX 项目V1.0、XX 项目1.01、."，然后在新的目录中进行修改； 但是这种方法，不仅十分繁琐，容易出错，而且会带来大量的垃圾数据。如果是团队协同开发或者是项目规模较大时，还是会造成很大的混乱。很显然，这样简陋的方法是无法应对这一问题的。后来，有人尝试从制造工业领域引入了"配置管理"这一概念，通过不懈的研究与实践，最终形成了一套管理办法和活动原则，这也就是软件配置管理。 通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报。 常见的配置管理工具 正如前面所述，由于软件配置管理过程十分繁杂，管理对象错综复杂，如果是采用人工的办法不仅费时费力，还容易出错，产生大量的废品。因此，引入一些自动化工具是十分有裨益的，这也是做好配置管理的必要条件。 正是因为如此，市场上出现了大量的自动化配置管理工具，这些工具的实现原理与基本机制
办公资源配置管理办法
办公资源配置管理办法 第一章总则 第一条为规范公司本部办公资源配置管理，提高公司办公资源配置效率，制定本办法。 第二条本办法适用于国华电力公司本部。 第三条本办法所称办公资源主要指公司为员工开展工作所配备的办公用品、办公设备、办公家具及行政办公应用系统资源。 第二章办公资源配置标准 第四条办公设备配置标准 注：各部门有多个办公室且相隔较远的，可单独配备打印机。 第五条办公家具配置标准
第六条行政办公应用系统配置标准 第七条办公用品配置标准 （一）一般岗位个人办公用品配置范围：文件夹、资料册、资料盒、U盘、移动硬盘、刻录盘、鼠标、鼠标垫、个人专用计算器等。 （二）部门公共办公用品配置范围：签字笔、自动铅笔、铅笔芯、铅笔、荧光笔、白板笔、直尺、橡皮、笔记本、信封、信纸、便签纸、复写纸、口取纸、N次贴、剪刀、裁纸刀、切纸刀、订书机、订书钉、推夹器、推夹器用夹、订夹扣、回形针、图钉、大头针、胶棒、涂改液、透明胶带、胶带座、双面胶、印泥、印油、长尾夹、橡皮筋、打孔机、计算器等。 （三）公司副总师以上领导办公用品根据实际需要配置。
第八条特殊岗位根据实际工作需要配置办公资源。 第三章办公资源配置办法 第九条本部办公用品实行定额管理，定额内根据工作需要领用。 （一）个人办公用品定额：部门经理以上80元/月，员工60元/月。 （二）部门公共办公用品定额：按照各办公室人员核定，20元/人月。 （三）复印纸、墨盒、硒鼓、碳粉等耗材按设备核定费用定额（不含楼层公共文印区设备）。定额内按实际消耗领用，超出定额需经总经理工作部审核，主管领导审批。 第十条办公设备中打复印、传真设备、扫描仪、固定电话、饮水机、碎纸机等由公司按标准统一配置，手机和笔记本电脑按以下办法配置。 （一）手机配置 1、公司副总师以上领导根据实际需要配置。 2、其他公司正式员工实行“公司定额补贴，员工自行购机”的形式配备。 3、购机补贴标准为1000元/人·年，首次购机另补1000元/人。
软件配置管理流程
软件配置管理流程
目录 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）根据确定的配置管理计划和相关规定，提交配置项
ISO20000-20配置管理程序
密级：敏感 文档编号：HTPC-ITSM-B-20配置管理程序 版本号：V1.0 配置管理程序 ************信息技术有限公司 ---------------------------------------------------------------------------- ************信息技术有限公司对本文件资料享受著作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。
修订履历
目录 1 目的 (4) 2 范围 (4) 3 职责 (4) 3.1 配置管理负责人 (4) 3.2 配置管理员 (5) 3.3 一线支持人员 (5) 4 相关文件 (5) 5 程序 (5) 5.1 配置计划 (5) 5.2 配置定义和标识 (5) 5.3 建立配置管理数据库 (5) 5.4 CMDB的控制和维护 (6) 5.5 配置审计和验证 (6) 5.6 生成配置报告 (6) 6 记录 (6)
1 目的 配置管理流程的总体目的是提供一个统一的、一致的流程来管理售后服务环境中的所有组成部分，以确保： 1)所有配置项（CI）被识别和记录下来； 2)配置项当前和历史状态得到汇报； 3)配置项记录的完整性得到维护和确认； 4)客户服务环境的稳定性； 5)实现资产管理的目的。 2 范围 配置管理的范围是公司开发的管理信息系统的运行和服务环境下所包含的配置项（CI），包括系统运行环境的部署环境设备、系统软件等，及服务环境中涉及的客户信息配置。具体活动包括识别、控制、汇报和审核等行为。 包括： 1)客户信息：企业客户信息； 2)软件信息：客户运行环境中传输线路综合管理系统、车辆管理系统及其运行环 境，安装软件的拷贝信息； 3)服务器端配置：主机设备、终端设备； 4)备件信息：手持终端设备、车载设备等； 5)服务文档：服务项目文档、服务记录、用户手册等； 6)供应商：供应商信息。 不包括： 1)处于开发或测试环境的业务系统。 3 职责 3.1 配置管理负责人 1)定义并维护配置管理流程文件及所需要的记录模板； 2)管理配置管理流程的实施； 3)确保配置管理流程目标的实现；
资源配置管理制度
资源配置管理制度 （试行） 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. 工作程序
人力资源配置和管理程序
发行版本：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人事部门所有培训员工必须有培训记录。
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各单位根据职业健康、安全、环境方针目标，于每年四季度提出下年度职业健康、安全、环境
软件配置管理控制程序
配置管理控制程序 历史记录
目录
1.引言 1.1目的 本程序文件定义了本组织的配置管理的过程，目的是规范公司的软件配置管理活动，使公司的所有软件开发项目的软件配置管理活动都能按照统一的要求进行。 1.2 使用范围 本文件适用于公司的所有软件项目。 1.3 名词和缩写 CM(Configuration Management) 配置管理 SCCB (Software Configuration Control Board) 软件配置管理控制委员会 CC (Configuration Controller) 配置管理员 工作产品（Work Products）：项目技术开发和管理工作中产生的有价值的成果，例如源代码、数据和各种文档。 配置项（Configuration Item, CI）：纳入到配置管理范畴作为单个实体对待的工作产品称为配置项[IEEE Std 610.12 - 1990 ]；配置项包括：项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入软件配置管理。 基线（Baseline）：一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。基线一经放行，就可以作为从配置管理系统检索源代码文卷（配置项）和生成可执行文卷的工具。 2角色与职责 2.1软件配置管理组（CM） CM组是项目里的一个小组，根据项目大小，可以由一个人，或者多人组成,小组的成员称为配置管理员(CC),通常由公司的质量保证组安排，加入到项目组，由项目经理领导。
CM组建立并管理配置管理库系统。 CM组负责组织相关部门和人员进行有关CM活动的培训。 项目组的CM组负责在该项目的整个生命周期中进行配置管理活动。 2.2软件配置管理控制委员会(SCCB) SCCB建立在项目级，通常由项目经理、该项目的技术经理、软件开发工程师、资深工程师、测试经理/测试工程师以及CC组成。SCCB在项目策划阶段由项目经理负责筹建。 配置管理控制委员会负责审批软件配置管理计划； 配置管理控制委员会负责审批软件基线的建立； 配置管理控制委员会负责审批对软件基线配置项的变更； 配置管理控制委员会负责审核和批准产品发布。 2.3 SCCB负责人 SCCB负责人通常由项目经理担任，代表SCCB在有关文件上签署意见。 2.4 项目经理 定期或事件驱动地评审或审核CM活动。 2.5 测试组 负责审核《配置管理计划》任务列表中与测试有关的内容 2.6 开发组 负责审核《配置管理计划》任务列表中与开发有关的内容 2.7 QA组 负责审核《配置管理计划》任务列表中与QA有关的内容
软件配置管理规范流程模板
软件配置管理规范 流程 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) 在配置管理系统中, 基线就是一个配置项或一组配置项在其生命周期的不同时间点上经过正式评审而进入正式受控的一种状态这些配置项构成了一个相对稳定的逻辑实体, 而这个过程被称为基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素( 配置项) 的一个版本, 且只确定一个版本。一般情况下, 基线一般在指定的里程碑处创立, 并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制, 基线中的配置项被冻结”了, 不能再
配置管理程序-运维体系
中烟信息运维体系建设__ITIL配置管理（一） 《配置管理流程》旨在介绍和描述中烟信息实施的配置管理流程，对中烟信息的生产环境IT基础架构和决策管理系统的配置信息进行管理和维护，使中烟信息的基础架构能够保障行业决策管理系统，使决策管理系统的配置信息能够及时准确的反映真实情况，保障决策系统的可用性。 配置管理数据库(Configuration Management Database, 简称CMDB)，至少应当保存各系统部件之间的关系，包括与该系统部件相关的事件、问题、变更请求。广义来讲，CMDB还可以用于存放事件、问题、已知错误，以及人员、供应商、地点、业务部门等公司数据。 在配置管理中，将列出IT基础架构中的IT设备的清单，关注于这些设备是何种设备、物理位置、设备的使用者、发生过多少次变更等。通常配置管理不会关注IT部件的价值或者何时租约到期。配置管理记录了IT部件之间的关系及其从属关系，以便为其他服务管理流程提供当前的、准确的信息。 1、流程概述 下图从总体上描述了配置管理流程、执行步骤和各步骤执行的顺序 图. 配置管理流程概述
配置管理流程起始于一个初始的规划和建设步骤，包括创建配置管理数据库（CMDB）。在初始化之后，该流程主要侧重于日常基础的鉴别和维护配置管理数据模型，以及维护配置数据。 2、流程步骤描述 (1)规划配置管理 该步骤的目的是规划和定义配置管理的目标、范围、政策和步骤，以及相关的组织结构、技术手段。其主要目的是创建配置管理数据库的初始数据模型。该流程由配置经理根据收集的配置信息发起并规划配置库的建立，形成具体政策由配置管理员对配置库建立和维护。 图. 规划配置管理流程 该步骤是配置管理的起始点。其目的是规划和定义配置管理的目标、范围、目的、政策和流程步骤，以及配置管理中涉及的人员组织。 初始设置、创建和发布配置管理数据库（CMDB），也是该步骤的工作内容之一。 输入： 初始的配置信息 任务： 1）创建配置管理计划 2）收集初始的配置管理数据 3）创建初始的CMDB 4）进行初始审核
资源配置方案
1.1资源配置方案 1.1.1角色和职责 1.1.1.1资源配置经理 ●管理所有活动，包括计划、识别、控制、审计及回顾。 ●负责资源配置管理流程。 ●通过审计流程确保CMDB的准确和真实。 ●把未经授权的CI变更升级至变更管理 ●为其他团队和流程提供有效的CMDB支持 ●生成流程报告 ●参与变更管理流程评估 ●审批CMDB的结构性变更 ●定义CMDB访问权限 ●定义CMDB ●作为资源配置管理流程文档这一资源配置项的责任人 ●评估资源配置管理管理流程并持续改进 1.1.1.2资源配置项责任人 ●确保所负责的CI的准确和真实 ●配合资源配置经理执行CMDB审计 ●在CMDB审计中负责进行差异分析，填写差异报告 ●记录所负责CI的所有变更 ●维护CI之间的关系 ●遵从资源配置管理流程 ●参与资源配置管理流程评估 1.1.1.3资源配置项审核员 ●配合资源配置经理开展CMDB审计工作
●负责对审计后纠正的结果进行抽查确认 ●与资源配置项责任人一起对CMDB中的记录进行对比审计 ●对审计后纠正的结果进行抽查确认 1.1.2流程目标 资源配置管理流程的总体目标是提供一个统一、一致的流程来管理网络所运维客户的IT生产环境中的协议承担的部分，以确保： ●所有资源配置项(CI) 能够被识别和记录； ●资源配置项当前和历史状态得到汇报； ●维护资源配置项记录的完整性； ●提高IT环境的稳定性； ●确保IT资产的有效控制和管理； 1.1.3流程描述 1.1.3.1资源配置管理总体流程
1.1.3.2资源配置管理规划
1.1.3.3资源配置项识别
1.1.3.4CMDB控制
如何制定配置管理流程
如何制定配置管理流程 【IT168 技术文章】 以下是我们在实际工作中遇到的一个例子，这个例子充分说明了正确的工作流程对于保证软件产品质量的重要意义。 1. 问题描述 某一开发团队为其客户开发业务软件，系统上线之后存在着很多的业务需求变更，同时也有很多业务部门在使用过程中所发现的软件缺陷，我们把需求变更和软件缺陷统称为变更。开发团队需要迅速响应客户所提出变更请求，把相应的软件版本修复及时地安装到生产系统上去。 为了保证产品质量，该开发团队建立了以下的软件发布流程： 图1 这四个环节分别对应以下四种环境： 开发环境：开发实现客户的变更请求 测试平台：开发团队把软件发布给客户之前做内部系统测试 准生产环境：客户把软件发布到生产系统之前做验收测试 生产系统：最终的生产系统 当开发团队将变更实现提交用户验收测试时，凡是没有通过验收测试的变更将被拒绝，只有通过验收测试的变更才会被部署到生产系统上去。整个流程如下图所示，假设开发团队总共实现了3个变更，其中变更1和变更2通过了系统测试被提交用户验收测试，但只有变更1通过了用户验收测试，最终只有变更1被部署到生产系统上。 3. 改进建议 为了避免以上所述的这些质量陷阱，我们应该改进现有的配置管理流程。 （1）建立闭环的质量保证流程 造成以上质量隐患的根本原因是系统代码没有被作为一个整体来处理，并且在发布过程中我们发布的是源代码，正确的流程（也是业界较为通行的做法）应该发布构建后的目标码而非源代码。我们可以建立一个闭环的质量保证流程（如下图所示）来批量地进行软件发布。
图6 其中系统测试过程中发现的缺陷应该被开发人员及时改正，然后再做构建，再测试，直到达到一个比较稳定的版本才会发布到验收测试环节。同样的，验收测试中发现的问题也会回到开发环节进行修复。这应该是一个多次循环的过程，不断地发现错误，然后改正，再测试。这个循环到什么时候结束呢？这个取决于各个软件项目的实际情况： 最理想的情况当然是到所有的缺陷都被改正为止，但是所花的时间比较长，可能赶不上项目的进度要求，现实工作不大可能做到这一点。 折衷的情况是所有严重的缺陷（即那些影响系统使用的的缺陷）都必须被改正，但允许有一些已发现的缺陷遗留到后面再去解决,前提是所遗留的缺陷不会影响其他变更的实现。大家平时在一些商用软件的新版本中经常可以见到发布说明（Release Notes）中所列的已知缺陷（Known Defects）就是属于这种情况。 我们向开发团队提出这个建议后，马上遭到项目经理的反对：“客户有些紧急的变更需要马上实现并交付生产运营，几乎没有时间来走这样完整的闭环流程。” （2）区别对待缺陷和新增功能 通过进一步了解我们发现紧急的变更一般是指影响系统正常使用的软件缺陷，这些缺陷需要及时的修复；而新增功能请求一般不是那么紧急的，允许开发团队有一段时间来开发实现。但开发人员目前是把所有紧急和非紧急的变更请求混杂在一起实现的，往往是一个紧急的缺陷已经修复，但另外一个正在开发中的新增功能也修改了同一组文件版本，造成两者之间的版本依赖，从而导致紧急的缺陷修复不能按时提交。 我们建议把缺陷的修复工作和新增功能的开发工作区分开来，这就涉及到多个版本的并行开发，开发团队主要面临以下三个版本的开发： v1.0中的缺陷修复 v1.0的新增功能版本v1.1 下一个版本v2.0 这样缺陷修复和新增功能开发相互独立，保证紧急的缺陷修复不会受到新增功能的影响。
配置管理程序范文
配置管理程序范文 1目的 控制对构成软件/硬件产品的各配置项的标识、管理、更改活动，保证配置项的完全性和正确性，防止非预期的使用，并能够有效的实现可追溯性。 2适用范围 适用于软件/硬件产品在整个生存周期中的控制管理活动。 3术语 ●配置：配置是指一个软件/硬件产品在生存周期的各个阶段所产生的 各个形式（机器可读或人工可读）和各种版本的文档、程序及其数 据的集合，该集合随着开发工作的进展而不断变化。 ●配置项：为了配置管理目的而作为一个单位来看待的硬件和/或软件 成分，或它们的集合体（软件项及开发文档都称为配置项）。 ●软件库：软件和有关文档说明的一个受控制的集合。目的是有助于 软件/硬件开发、使用和维护。包括开发库、受控库和产品库等。 ●开发库：指在软件生存周期的某一个阶段期间，存放与该阶段软件/ 硬件开发有关的计算机可读信息和人工可读信息的库。 ●受控库：指在软件/硬件生存周期的某一个阶段结束时，存放作为阶 段产品而释放的、与软件/硬件开发工作有关的计算机可读信息和人 工可读信息的库。配置管理就是对受控库中的各个软件项进行管理， 因此受控库也叫做配置管理库。 ●产品库：指在软件/硬件生存周期的组装与系统测试阶段结束后，存 放最终产品而后交付给用户运行或在现场安装软件库。 ●软件项：是指组成最终产品的源代码、中间文件、目标运行代码， 构成安装程序的源代码、中间文件、目标运行代码以及产品的联机 帮助说明文件（源代码包括程序代码、头文件、资源文件等）。 4职责 项目负责人是配置管理活动的总负责人。其主要职责是制定《配置管理计划》，组织配置管理活动的实施并对实施效果进行监督检查，协调配置管理活动中的有关事宜。
软硬件配置管理程序
三阶文件 软硬件配置管理程序 文件编号：MLK-I-078 版本号：A.0 项目页次 0.0 封面 (1) 1.0 目的 (2) 2.0 适用范围 (2) 3.0 硬件配置 (2) 4.0 电脑软件配置 (8) 5.0 软硬件使用 (10) 6.0 硬件配置表 (11) 7.0 软件安装申请单 (12) 8.0 文件修订记录表 (13) 核准：审核：编制：日期：日期：日期：分发号：
1.0目的: 1.1使各部门在申购、调配、更新电脑及相关硬件有统一、规范标准可依； 1.2使用各工作岗位使用的电脑软硬件环境符合其实际工作配置要求； 1.3合理安排IT资源，更大发挥功能，节约IT的成本支出； 2.0适用范围: 本程序适用于公司各部门. 3.0 硬件配置： 所有的硬件分为零配件辅料和整机两个部分，零配件辅料部分：主板、CPU、硬盘、U盘、内存、显卡、主机电源、主机电源线、CPU风扇、网线、网卡、水晶头、光驱等；电脑设备及外设部分包括：服务器、电脑主机、显示器、交换机、路由器、磁带机、扫描仪、条码枪、UPS、数码相机等，其中电脑主机按实际用途进行分类。 3.1电脑级别的定义： 公司所有的申购电脑按实际工作角色分以下几等级： A级：文职类，日常工作主要从事文职类的工作使用的电脑，如部门主管、职员、非设计类办公人员等 B级：工程类，日常工作主要从事工程设计工作使用的电脑，如电子、3D、平面、程序设计人员使用的电脑，分B1、B2、B3、B4四个级别 B1、3D设计类：从事产品外形、结构、模具等设计工程使用的电脑 B2、平面设计类：从事产品包装等设计工程使用的电脑 B3、电子设计类：从事产品电子电路设计工程使用的电脑 B4、程序设计类：从事各应该程序、驱动设计工程使用的电脑 C级：测试类，主要用于生产线测试工作使用的电脑 D级：仪器设备专用类 3.2电脑硬件配置（适用于新购电脑） 为保证新购电脑的稳定性、可用性、低成本，在选购电脑时，原则不使用各硬件厂商当年新推出的硬件产品，同时硬件配置跟据市主流配置和实际工作需求而定，具体如下：
软件配置管理规范流程
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） 在配置管理系统中，基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，这些配置项构成了一个相对稳定的逻辑实体，而这个过程被称为“基线化”。每一