项目配置管理过程规范(精编文档).doc
- 格式:doc
- 大小:309.56 KB
- 文档页数:15
项目配置管理过程规范文档种类:研发体系发行范围:研发中心变更记录目录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审批。
配置审计:可以分为物理审计和功能审计。
前者审查配置项的外在特征的正确性与一致性;后者审查配置项内容的正确性与一致性。
物理审计的内容包括:⏹确认配置项标识的正确性;⏹确认已受控配置项的更改是受到控制的;⏹验证配置库内容与相应记录之间的一致性;⏹验证配置管理活动与相应记录之间的一致性;⏹验证配置管理工作是否符合适用的标准和规程;⏹验证配置管理系统与系统备份的有效性、一致性等。
配置管理(Configuration Management, CM)的目的是通过执行版本控制、变更控制等规程,以及使用配置管理软件,来保证所有配置项的完整性和可跟踪性。
配置管理过程域的四个主要规程:制定配置管理计划-配置库管理-配置版本控制-配置变更控制定义1.工作成果(Work Product)项目研发和管理过程中会产生许许多多的工作成果,例如文档、程序和数据等。
2.配置项(Configuration Item, CI)所有纳入配置管理范畴的工作成果统称为配置项,配置项主要有两大类:(1)属于产品组成部分的工作成果,例如需求文档、设计文档、源代码、测试用例等。
(2)项目管理中产生的文档。
如计划、报告等。
这些文档虽然不是产品的组成部分,但是值得保存。
每个配置项的主要属性有:标识符、名称、文件状态、版本、作者、日期等。
所有配置项都须保存在配置库里,确保不会混淆、丢失。
配置项及其历史记录反映了软件的演化过程。
3.基线(Baseline)基线由一组配置项组成,并且这些配置项已被“冻结”,任何人不能再随意修改(见变更控制规程)。
基线通常在里程碑处建立,所以一个产品可以有一个或多个基线。
基线的主要属性有:标识符、名称、版本、日期等。
通常将交付给客户的基线称为一个“Release”,为内部开发所用的基线则称为一个“Build”。
4.项目配置管理员(Project Configuration Manager)为了提高配置管理的效率和安全性,项目需要有专人为项目制定《配置管理计划》,创建和维护配置库,在本文档中,该负责人称为项目配置管理员。
在公司,项目支持负责人担任项目配置管理员的角色。
5.项目变更控制委员会(Change Control Board, CCB)项目CCB对项目内配置管理的各项活动拥有决策权(例如审批配置管理计划,审批变更请求等)。
对于配置管理而言,项目CCB是决策者,而项目配置管理员是执行者。
配置管理规范配置管理规范是一份组织或企业制定的,用于管理配置项的规定和流程的文件。
它的目的是确保配置项的正确性、一致性和可追溯性,以提高配置项的管理效率和可靠性。
下面是一份配置管理规范的典型内容,共有以下几个方面:1. 配置管理目的配置管理的目的是确保项目的稳定性、可靠性和一致性。
通过合理的配置管理流程,可以减少配置变更对项目的风险和影响,提高项目的质量和效率。
2. 配置管理团队配置管理团队由配置管理员和相关团队成员组成。
配置管理员负责实施和维护配置管理规范,相关团队成员负责配合配置管理工作的实施。
3. 配置管理流程配置管理流程包括配置项的识别、控制、状态管理和审计。
其中,配置项的识别是指对项目中的配置项进行标识和归类;配置项的控制是指对配置项的变更进行管理和控制;配置项的状态管理是指跟踪和记录配置项的状态变化;配置项的审计是指定期对配置项进行审查和验证。
4. 配置项的标识配置项的标识是指每个配置项都有一个唯一的标识符,用于标识和跟踪配置项的变更和状态。
标识符可以是一个编号、一个名称或一个组合的字符序列。
5. 配置项的分类配置项应按照其功能和特性进行分类。
常见的分类包括硬件配置项、软件配置项、文档配置项和人员配置项等。
6. 配置项的变更管理配置项的变更应按照变更管理流程进行控制和审批。
任何对已经配置发布的配置项的更改都必须通过变更管理流程进行审批和记录,确保变更的正确性和有效性。
7. 配置项的版本管理对于代码或软件配置项,应实施版本管理,通过版本号和版本控制工具进行管理,以确保配置项的版本一致性和可追溯性。
8. 配置项的备份和恢复对于关键配置项,应定期进行备份,并测试备份的可恢复性。
备份和恢复的策略和流程应与配置管理流程相衔接,确保配置项的完整性和可恢复性。
9. 配置管理的培训和治理配置管理规范应被广泛传达和培训给相关人员,以确保配置管理流程的全面实施。
同时,应定期对配置管理流程进行治理和改进,以适应项目变化和技术发展的需求。
项目管理实施流程规范目录一前言 (3)1.1目的 (3)1.2使用范围 (3)1.3角色成员 (3)二项目实施总流程 (4)2.1流程总图 (4)2.2说明 (4)三项目启动 (4)3.1流程描述 (5)3.2输入输出 (5)四需求调研(分析) (5)4.1流程描述 (5)4.2输入输出 (6)五概要设计 (6)5.1流程描述 (6)5.2输入输出 (7)六详设开发测试 (7)6.1流程描述 (7)6.2输入输出 (8)七联调测试 (8)7.1流程描述 (8)7.2输入输出 (9)八试运行维护 (10)8.1流程描述 (10)8.2输入输出 (11)一前言1.1目的为规范项目管理工作,指导项目经理及相关人员按照规范的流程实施项目,使各项目都处于可跟踪状态,确保项目实施的质量和效率,特编写本文档。
1.2使用范围该实施规范适用于****类型项目。
1.3角色成员二项目实施总流程2.1流程总图2.2说明重点控制环节:项目计划、测试(功能、性能及安全)、联调测试。
三项目启动3.1流程描述【P1-01】:项目经理制定项目计划。
确定了执行、监控和结束项目的方式和方法,包括项目需要执行的过程、项目生命周期、里程碑和阶段划分等全局性内容。
对项目进度管理、项目资源管理、项目费用管理、项目风险管理、项目质量管理等管理思路和方法进行阐述。
项目管理计划包括项目质量管理计划、项目风险管理计划、项目集成管理计划、项目进度/费用/资源等监控管理计划、项目变更管理计划等。
【P1-02】:项目经理使用工作分解结构(WBS)将项目工作组织成为若干个工作包,并给出一个范围说明来详细地描述这项工作。
明确关键可交付成果:列出并描述项目中的关键产品。
它还应当描述这些可交付成果的质量预期。
包括数据迁移相关工作。
【P1-03】:项目计划经过内部及外部评审(万达、用户方参与)。
【P1-04】:评审通过后进入下一阶段。
3.2输入输出【输入】➢项目合同【输出】➢项目计划➢WBS任务分解➢评审报告四需求调研(分析)4.1流程描述【P2-01】:项目经理根据合同和项目关键里程碑节点计划以及与用户协商的结果(需求调研的对象和调研的时间),编制(或细化)《需求调研计划》并发送给需求调研分析人员。
软件配置管理规范版本:V1.0目录文件版本历史 (I)1介绍 (1)1.1目的 (1)1.2范围 (1)2规范概述 (1)3规范详述 (1)3.1配置库管理规范 (1)3.1.1配置库说明: (1)3.1.2角色职责 (2)3.1.3配置库结构: (2)3.1.4配置库权限设置: (3)3.1.5配置库备份机制: (3)3.2配置项管理规范: (4)3.2.1配置库建立 (4)3.2.2配置项识别: (4)3.3基线管理规范: (5)3.3.1基线说明: (5)3.3.2基线分类: (5)3.3.3基线命名规则 (6)3.3.4在Team Foundation Server中创建基线 (6)1 介绍1.1 目的本规范目的在于指导配置管理人员如何利用配置库管理所有配置项,从而加强对公司软件产品的控制,保持软件产品在其整个生命周期中的一致性、完整性、可追溯性。
1.2 范围本规范适用于重要软件产品和软件项目的配置项管理。
对于非重要软件或已开发好的软件,可以采用本规范规定的要求的子集。
2 规范概述本规范应用于软件配置管理过程,主要包括配置库的设置,配置项的标示,基线命名等。
3 规范详述3.1 配置库管理规范整个项目开发中,把所有的工作成果存放在四个库中,分别为:代码库、文档库、基线库、项目产品库,其中前三个库存放到配置管理工具数据库中,项目产品库建立在文件服务器XXX目录中,根目录名称为项目编号。
3.1.1 配置库说明:代码库(CodeLib):存放项目开发过程中的源代码,开发人员对其有编辑、修改、删除等操作权限。
文档库(DocumentLib):存放项目计划中定义配置项文档(项目计划、需求文档等)和支持文档(周报、会议记录等)。
基线库(BaselineLib):存放项目中已发布的项目基线。
项目产品库(ProductLib):存放对内发布的产品,由于程序文件都一次生成,不需要进行版本管理的,所以项目产品库存放在文件服务器上。
配置管理规范文件精选配置管理规范文件精选引言配置管理在软件开发和项目管理中具有重要作用。
它有助于确保项目的顺利进行,避免出现混乱和重复。
配置管理规范是一套指导和规则,确保团队在开发过程中遵循统一的标准和流程。
本文将重点介绍配置管理规范文件的精选内容和相关要求。
配置管理规范概述配置管理规范适用于各类软件开发项目,旨在确保项目的顺利进行并提高团队协作效率。
规范的主要目的包括:1、确保项目的配置项得到有效管理,避免版本冲突和混乱;2、统一团队的配置管理流程,提高工作效率;3、为项目成员提供明确的配置管理指导,减少潜在问题;4、确保配置项的可追溯性和可管理能力。
配置管理规范的原则配置管理规范遵循以下原则:1、唯一性:为每个配置项分配唯一标识,确保项目中的唯一性;2、可追溯性:记录配置项的版本信息,方便追溯历史记录;3、可重复性:确保配置项在不同的环境中能够重复构建成功;4、安全性:保护配置项不被未经授权的人员访问或篡改。
配置管理规范的具体要求配置管理规范对文件的要求如下:1、文件命名规范:文件名应采用有意义的名称,避免使用空格和特殊字符,确保文件名的准确性;2、文件夹结构要求:建立合理的文件夹结构,确保文件分类清晰、组织有序;3、文件权限控制:为文件分配适当的权限,确保只有授权人员能够访问和修改文件;4、版本控制:使用版本控制系统(如Git)来管理文件版本,确保每个配置项都有一个唯一的版本号;5、文档记录:记录配置项的详细信息和变更历史,方便后期查询和追踪;6、配置项识别:为每个配置项分配唯一标识,确保项目中的唯一性;7、配置项存储:合理存储配置项,避免配置项丢失或混乱;8、配置项备份:定期备份配置项,确保数据安全和可恢复性;9、问题追踪:及时追踪配置管理过程中出现的问题,并采取相应措施加以解决。
常见问题及解决方案在配置管理过程中,可能会遇到以下常见问题:1、版本冲突:由于多个成员同时修改同一文件,导致版本冲突。
(项目管理)项目配置管理规范目录1.简介11.1目的11.2范围11.3文档结构11.4词汇表11.5参考信息21.5.1可追溯性21.5.2方针21.5.3过程/规范21.5.4指南21.5.5模板21.5.6检查表21.5.7培训21.5.8工具21.6参考网站32.配置管理规范32.1配置管理流程图3 2.2角色32.3进入准则42.4输入42.5活动42.6输出52.7验证与确认5 2.8退出准则62.9度量63.变更控制规范73.1变更控制流程图7 3.2角色83.3进入准则83.4输入83.5活动83.6输出83.7验证与确认9 3.8退出准则93.9度量94.参考文献9附录 A –流程框图符号10附录B 文档命名指南111.简介软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。
1.1目的本文档指导项目开展配置管理活动。
1.2范围本文档适用于托普信息(iTOP)集团技术委员会批准立项的软件项目。
1.3文档结构第一部分:简介,包括本规范的目的、范围、词汇以及所涉及到的参考信息。
第二部分:配置管理工作规范的正文,包括活动的流程图、进入以及退出准则、所涉及的角色、相关活动的阐述、验证与确认以及度量。
第三部分:变更控制工作规范的正文,包括活动的流程图、进入以及退出准则、所涉及的角色、相关活动的阐述、验证与确认以及度量。
第四部分:参考文献,列出了编写本规范所参考的相关的文献资料。
第五部分:附录,本文中流程图的标准符号定义。
1.4词汇表CM(Configurationmanagement)配置管理。
CCB(Changecontrolboard)变更控制委员会。
CI(Configurationitem)配置项,包含文档、程序。
CR(ChangeRequest)1变更请求,对提出的要变更工件或流程的任何请求的统称。
在变更请求中记录的信息是有关当前问题、提议解决方案及其成本的起源和影响的信息。
1.1总经理............................................................2..1.2 项目总监.........................................................2.1.3 项目经理.......................................................... 3.1.4 财务经理......................................................... 3.1.5 项目人员.......................................................... 3.2.1 项目立项.......................................................... 4.2.2 项目计划......................................................... 5.2.3 项目变更.......................................................... 6.2.4 项目执行.......................................................... 6.2.5 项目跟踪......................................................... 7.2.6 项目收尾.......................................................... 7.3.1 沟通管理......................................................... 8.3.2 报价管理......................................................... 8.3.3 合同管理.......................................................... 9.3.4 外包管理.......................................................... 1.0 3.5 文档管理.......................................................... 1.1 3.6 绩效管理.......................................................... 1.1..........................................4.1 基本素质(-5) .................................................... 1.34.2 应具备的特质(-9) ................................................ 1.34.3 能力要求(-4) .................................................... 1.34.4 基本责任.......................................................... 1.54.5 项目综合管理...................................................... 1.6公司以项目为核心,涉及总经理、项目总监、项目经理、财务经理和项目人员,相应的职责分工为:协助项目经理进行项目管理,全程跟踪并监控所有项目的情况(重点为项目预算、项目进度、项目费用和项目质量)。
项目流程管理规范1. 引言本文档旨在制定项目流程管理规范,确保项目能够按照预定的计划和流程顺利进行。
项目流程管理规范适用于所有的项目,并旨在提供一套可执行和标准化的流程指南。
2. 规范内容2.1 项目启动- 在项目启动阶段,明确项目目标和范围;- 完成项目可行性研究和风险评估;- 确定项目组成员和相关职责。
2.2 项目计划- 制定详细且具有可操作性的项目计划;- 确定项目的时间和资源需求;- 制定项目进度管理计划。
2.3 项目执行- 按照项目计划,有序地执行项目任务;- 及时跟踪项目进度,并及时解决项目执行过程中的问题;- 在项目执行阶段进行合理的风险管理。
2.4 项目监控与控制- 设立有效的项目监控机制,定期掌握项目进展情况;- 采取措施进行项目控制,确保项目按照计划进行;- 及时修正项目计划和资源分配,以应对项目风险和变动。
2.5 项目收尾与总结- 完成项目交付,并进行验收;- 对项目过程进行总结和评估;- 形成项目经验库,为以后的项目提供借鉴和改进。
3. 相关责任部门- 项目发起人负责项目启动和目标设定;- 项目经理负责项目计划和执行;- 项目监控人员负责项目监控与控制;- 质量管理团队负责项目质量的管理和保证。
4. 附则对于特定项目的流程管理规范,可以根据实际情况进行调整和补充。
项目流程管理规范应与公司内部的其他管理规范和标准相协调,确保项目的高效管理和顺利推进。
5. 结论项目流程管理规范是项目管理中的重要工具,通过合理规范项目流程,能够提高项目的成功率和效率。
所有项目参与者应遵守本规范,共同推进项目的顺利进行。
配置管理规范对于一个一般的项目来说,配置管理规范的内容至少需要包括以下的内容:1、配置项及其命名规则;2、配置库文件目录结构;3、角色和权限定义;4、配置项变更流程;5、配置项发布;6、基线定义和基线变更。
配置项及其命名规则对我们的项目来说,配置项需要包括以下的内容:1、项目管理过程文档;a) 项目任务书;b) 项目计划;c) 项目周报;d) 个人日报和周报;e) 项目会议纪要;f) 培训记录和培训文档;2、QA过程文档;a) QA不符合报告;b) QA周报;c) 评审记录;3、工作产品a) 需求文档;b) 设计文档;c) 代码;d) 测试文档;e) 软件说明书和手册;4、项目中使用的第三方产品上文中用红色部分标识的是容易遗漏的配置项,尤其是第4个(项目中使用的第三方产品),实际上,一个工程型的项目会大量使用第三方的软件(例如,我们的产品中就使用了IBM的MQSeries、Oracle、一些第三方的开发控件),对这些产品的管理至少可以解决三个方面的问题:1、版本配合的问题:大部分的第三方软件在升级之后,并不能实现二进制层面上的兼容,需要对原有的代码重新编译;甚至有的第三方软件在升级之后,API层面上的兼容性都做不到;因此,在工程实施的过程中,版本的配合问题是一个需要关注的问题;2、发布的完整性问题:一般来说,比较大型的第三方软件在发布过程中都不会有遗漏,但对一些小的第三方软件来说,比如我们使用的许多perl的CPan模块,如果在开发过程中没有有意识的进行管理的话,很容易就会发生遗漏;3、在某些特殊条件下由于第三方软件的变化引起的基线变更:这种情况极少会发生,但在我们以前的项目中,确实还遇见过。
一般是因为原来选型时使用的第三方软件不能满足要求,只能通过更换新的第三方软件,这就补课避免地需要变更基线(例如需求文档、设计文档等);将第三方软件纳入配置管理的范畴可以更方便地管理基线的变更。
关于第三方软件产品配置项的管理还有一点需要说明:由于第三方软件有可能会比较大,而且相对我们的项目来说,是很少会发生变更的(一般在一个项目过程中,不会采用不同的配置项的命名可以便于查找相关配置项。
【最新整理,下载后即可编辑】
项目配置管理过程规范
文档种类:研发体系发行范围:研发中心
变更记录
息,以保证其可追溯性。
目录
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审批。
配置审计:可以分为物理审计和功能审计。
前者审查配置项的外在特征的正确性与一致性;后者审查配置项内容的正确性与一致性。
物理审计的内容包括:
⏹确认配置项标识的正确性;
⏹确认已受控配置项的更改是受到控制的;
⏹验证配置库内容与相应记录之间的一致性;
⏹验证配置管理活动与相应记录之间的一致性;
⏹验证配置管理工作是否符合适用的标准和规程;
⏹验证配置管理系统与系统备份的有效性、一致性等。
功能审计的内容包括:
⏹验证当前基线所含配置项对前一基线所含配置项的追溯性;
⏹确认当前基线所含配置项均正确反映了项目需求;
⏹评估基线的完整性;
⏹验证当前基线和各基线间所含配置项的一致性;
验证配置库内容的完备性和正确性等。
2. 职责说明
3. 输入
《项目计划》
4. 入口准则
《项目计划》已经形成文档并通过评审。
5. 活动
5.1. 活动关系图
5.1.1. 配置管理流程图
配置管理过程
输入
项目经理
项目成员
输出
配置管理员
CCB
制定配置管理计划
执行配置管理
编写配置管理计划
建立项目配置库
提交工作成果
结束
配置管理计划
开始
评审配置管理计划
申请建立基线
执行配置审计建立并发布基线
项目计划
基线建立申请表
配置状态报告
CCB 审批
批准?
Yes
No
配置审计报告
属于基线?
Yes
配置项入受控库No
配置状态跟踪
5.1.2. 配置变更流程图 配置变更流程
输入项目经理项目成员输出
配置管理员CCB 基线变更配置项变更配置项变更申请
配置项变更结束
开始
基线变更申请
执行变更
验证变更
变更申请及跟踪记录配置状态报告
变更审批
通过
不通过配置审计报告批准变更
更新基线配置审计
通过
不通过结束
开始
配置状态报告
备注说明:对于配置变更,应先进行审计,后更新基线。
5.2. 活动描述
5.2.1. 制定配置管理计划 1. 在项目策划阶段配置管理员起草配置管理计划,项目经理给予必要的协助。
2.配置管理计划要进行评审,参与人员是CCB、项目经理及其他相关人员。
5.2.2. 建立配置库
1.配置管理计划完成后,配置管理员建立项目配置库,按组织统一规定建立
项目配置库目录结构,并设置访问权限。
a)项目配置库名称的命名规则:项目名称的英文缩写(或拼音缩写)。
b)纳入基线配置项的命名规则:项目名称_文档名称。
2.配置库建立完成后,配置管理员邮件通知项目组全员。
5.2.3. 建立配置项
项目成员按配置管理计划,将配置项提交到自己有权限的配置库目录内。
配置管理员每月提交配置项状态报告
5.2.4. 基线建立及发布过程
1.基线所属的配置项,全部经过同行评审并解决了评审中提出的问题,由项
目经理验证后,填写《基线及产品发布申请单》
B对申请进行审批,审批通过后由配置管理员执行配置检查,然后可以
建立并产品基线。
一般项目要建立的基线见下面的基线分类表。
表格 5-1 基线分类表
3.
果发布给CCB及项目组全体成员。
5.2.5. 配置变更
●配置项变更
1)出现以下情况时一般需要对配置项进行变更:
⏹测试发现错误。
⏹文档内容发生较大变化。
⏹CM审计发现较大错误。
⏹其他变更要求。
2)非基线的配置项变更只要做到及时通知项目经理,由项目经理认可即
可。
●基线变更
1)基线的变更来源包含两个方面的因素:
⏹基线化的配置项发生重大的变更。
⏹基线建立有误。
2)当配置项发生重大变更时,由项目经理向CCB提交基线变更申请,由
CCB评估并审批是否可以对基线进行变更。
3)CCB审批通过后,由项目组成员执行变更。
4)CCB对变更进行验证。
5)由配置管理员进行物理审计,并填写《配置审计报告》。
6)配置管理员更新基线,并编写或更新《配置状态报告》。
5.2.
6. 配置审计
1.基线发布前或变更后,配置管理员需要执行物理审计以保证配置项的完备
性;
2.基线发布前,由项目经理组织基线所属文件的功能审计;
3.配置审计结果记录在《配置审计报告》中,如有问题由配置管理员统一跟
踪解决直到关闭。
5.2.7. 备份
配置库备份方式:配置管理员每周备份配置库,采用增量备份方式,但每两个月要完全备份一次。
6. 输出
《配置管理报告》
《基线变更记录》
《基线及产品发布申请单》
7. 出口准则
项目结束并通过验收。
8. 本过程裁剪规定
●小型项目的配置审计可以只做发布前的审计。
●配置库备份可由组织配置管理人员统一执行。