配置管理规范.docx

配置管理规范.docx

《配置管理规范.docx》由会员分享，可在线阅读，更多相关《配置管理规范.docx（9页珍藏版）》请在冰豆网上搜索。

配置管理规范

配置管理规范

配置管理规范

文件控制文档编号分册名称总页数编制

受控不受控

版本号

第册/共册

正文审批

附录生效日期

文件类型

修改变更记录：

更改条款及内容

更改人

审批人

更改日期

-2-

文件类型

12345

目的3范围3术语3职责3程序4

配置管理中的阶段划分4配置管理策划与计划5配置库建立5

配置管理工具5配置库结构5配置库存取权限控制5配置库文件存取时间控制6

配置项标识6配置控制6

配置项和软件基准的存储控制6配置库结构层次的变更错误！

未定义书签非基准配置项的变更控制错误！

未定义书签基准配置项的变更控制7变更信息沟通7

配置状态跟踪7配置审计8

配置审计的目的与时机8配置审计工作准备8

配置管理9

配置库结构层次和内容9基准配置项的变更与完善界定9版本控制9源代码和可执行程序的配置规定10现场开发、实施的相关配置管理规定10

-1-

文件类型

67

相关文件错误！

未定义书签记录错误！

未定义书签

-2-

文件类型

1目的

本文件规定了项目进行过程中配置管理活动的流程以及组织对配置管理的具体要求公司项目过程中的配置活动必须以本文件的规定进行实施配置管理

2范围

本文件适用于公司项目全过程中的软件配置活动，包括项目的配置计划，配置评审，配置实施，配置变更等等

3术语

配置项：

项目开发或系统集成实施过程中所需要或所产生的软件、硬件、工具、释放产品、文档，包括基准配置项与非基准配置项

基准配置项：

通过正式评审成为下一步开发或实施基础的配置项，只有通过规范要求的变更控制程序才能被更改

更改：

配置项的变更与更改统称为更改

（）：

配置审计报告

4职责

――配置管理负责人

负责制定配置管理计划，并在项目进行过程中按照计划执行配置管理活动，实时更新项目的“配置状态报告”和《配置库结构层次图》，并向所有受影响的项目组和个儿通报当前配置管理状态

――软件质量保证负责人

负责根据《软件质量保证计划》的安排实时跟踪项目软件配置管理的实施情况；参与配置审计并跟踪纠正/预防措施的执行情况直到问题关闭――项目经理/项目软件经理（PM/）

负责协调配置管理活动实施，协同配置管理负责人管理项目配置库；参与配置审计，会同

-3-

文件类型

项目相关人员实施确定的纠正/预防措施

5程序

配置管理中的阶段划分

配置管理阶段划分图

阶段

输出

配置管理计划

结构层次图

说明

编写项目计划的同时编写配置管理计划，并与项目计划同时进行评审

配置管理策划

阶段

配置管理实施

阶段

配置库结构层次图

配置库

配置库结构层

次变更

结构层次图

变更后通知受影响组织和个人

变更后通知受影响组织和个

人

配置库

软件基准变更

结构层次图

评审报告

基准配置项变更需要进行评审通过

配置审计配置库

结构层次图

对配置中的不合理项进行纠正和修改

配置备份

配置库数据文件

根据配置管理计划进行配置备份，或在基准配置项变更后进行备份

注：

红色部分需要进行评审

-4-

文件类型

根据配置管理过程中不同时期不同侧重点，配置管理活动划分为以下几个阶段：

配置管理策划阶段；配置管理实施阶段；配置库结构层次变更；软件基准变更；配置审计；配置备份

配置管理策划与计划

通常情况下，在项目产品策划阶段制定配置管理计划配置管理计划一般包含人员职责，配置管理软硬件资源描述，配置项描述，基准配置项描述，项目成员的操作权限划分以及备份方案等

配置管理计划的制定由软件配置管理负责人在开发策划阶段根据项目经理/项目软件经理的任务分解及进度安排情况制定具体内容可参照《配置管理计划》模板和《配置库结构层次图》

配置库建立

配置管理工具

常见的配置管理工具有微软公司的公司常规软件项目产品开发所使用的开发工具为Vs和Vs

配置库结构

项目立项后，配置管理负责人即可根据评审后的《配置库层次结构图》建立项目配置库，为保证配置项目录的顺序可在目录名前加上序号进行确认

配置库存取权限控制

配置管理负责人按照项目计划并和项目经理充分沟通的情况下来设定项目组及有关人员对配置库的存取控制，并且负责在项目进行中维护配置库的存取权限

-5-

文件类型

配置库文件存取时间控制

对配置库进行操作的人员，对公共部分的文件的时间间隔不能过长，以方便其他人进行共享操作通常情况下在配置管理策划过程中应明确项目文档、需实时更新的各种记录以及源代码、可执行程序的操作间隔时间，以保证查阅人员可以及时从配置库中获取最新信息配置审计过程中可将文件存取时间作为审计内容之一

配置项标识

开发过程中要标识的配置项主要包括以下几部分：

1）开发环境与测试环境：

软件工具、硬件设备等；2）开发工具：

自动设计工具、测试工具、维护工具等；3）项目文档：

立项建议报告、可行性分析报告、项目计划、软件需求规格说明书、任务分解书、质量保证计划、系统设计报告、测试文档、技术报告、项目总结报告、系统集成方案、交付和安装记录等；

4）质量记录：

各类评审记录和表格文档，如《项目任务书》、《变更控制报告》、《软件需求变更记录》等；

5）提交产品：

源代码、可执行程序、联机帮助、用户手册等标识要求

1）在开发与实施过程中项目组人员提交的文档，按照《标识规范》进行标识；

2）合同有明确标识和追踪要求时，按合同要求进行标识，以保证满足合同的追踪要求；3）外购产品使用原有标识；

4）在《标识规范》中没有明确要求的项目进行过程中形成的中间文档，在纳入配置前应加以唯一标识，文档类别代号可自行采用合适的英文缩写

配置控制

配置项和软件基准的存储控制

配置项的存储

在项目立项后，投标书、方案等市场前期策划的文档及相应评审记录由配置管理负责人从市场人员处获得放入市场前期策划阶段子目录下进行保存；启动阶段的技术和表格文档及相应的评审记录等由项目组和配置管理负责人放在配置库的启动阶段子目录下进行管理和控制；进入实施阶段，项目组人员按照配置管理计划及时提交配置项，通过评审的配置项及评审记录，放在项目组的配置库里，同时配置管理负责人进行备份项目基准配置项的建立

-6-

文件类型

项目组人员提交的配置项按照《评审规程》进行正式评审通过后即可作为基准配置项，并由配置管理负责人将成为基准的配置项及相应的评审记录放入配置库中，以便进行管理和控制；同时部门项目管理人员及时在部门服务器中对基准配置项进行备份

基准建立后，需将基准内容及时在“配置状态记录”中进行记录并通知所有受影响的部门、项目组和个人

基准配置项的变更控制

变更请求的提出

客户或开发部门要求变更已建立的基准配置项、重要的项目组成员、重要的项目资源时，一定要填写《变更控制报告》填写《变更控制报告》时，要求进行变更请求说明和变更评估，变更评估时要考虑以下几种情况：

1）一般情况下，变更评估要考虑变更对其它配置项尤其是对当前基准配置项的影响及变更的效果；

2）如果变更较大，还要评估变更对项目进度、成本和质量的影响；3）如果变更是为了增加需求，还要将报价单交给客户审批变更请求的审批与实施

按照《评审规程》的要求，部门项目管理人员组织对本次变更的评审，建议的变更请求被批准，由部门项目管理人员负责跟踪相应变更的实施

变更信息沟通

配置库中任何信息的变更实施结束后，配置管理负责人在将对配置库中内容进行调整、更新《配置库结构层次图》和相关“配置状态记录”的同时必须将变更的信息通知给所有受影响的部门、项目组和个人

配置状态跟踪

配置库可以通过《配置库结构层次图》和《项目配置状态报告》进行状态跟踪，要求《配置库结构层次图》和《项目配置状态报告》始终保持最新状态

-7-

文件类型

配置审计

配置审计的目的与时机

配置审计的目的在于力图发现和报告项目配置管理工作中的缺陷并跟踪缺陷的解决情况

配置审计的内容如下：

验证基准配置项内容的完整性和正确性；配置管理系统的结构和设施；配置管理工作是否遵循组织程序文件；

配置审计工作有项目管理人员组织并实施，并出具《配置审计报告》，参见《配置审计报告》模板

配置审计的时机分为两种策略：

一种是定期进行配置审计；另一种通常为项目进入到总结阶段或每次基准配置项发生重大变更时

配置审计工作准备

确认审计组人员

审计组成员包括配置管理负责人、项目经理/项目软件经理、开发人员或实施工程师以及项目的软件质量保证负责人

1）项目管理人员：

负责审计工作准备和审计实施，协助项目的质量保证负责人L跟踪来自审计的纠正/预防措施直到关闭编写“配置审计报告”，提交给项目的配置管理负责人并保存在项目配置库中；

2）配置管理负责人：

对于审计中发现的配置缺陷，采取必要的纠正措施；

3）项目经理/项目软件经理：

对于审计中发现的软件工程缺陷，采取必要的纠正措施；4）开发人员或实施工程师：

必要时一些开发人员或实施工程师参与审计组，提供相关的技术支持；

5）软件质量保证负责人：

参与配置审计并跟踪来自审计的纠正/预防措施直到关闭确认审计日程安排

准备配置审计检查表，参照《配置审计报告》模板

-8-

文件类型

配置管理

配置库结构层次和内容

根据《配置库结构层次》图中提供的软件生命周期划分的通用目录结构结合项目的具体特点做相应适当的调整按项目计划和阶段进度表中计划提交的“阶段成果”内容，在配置管理策划时确定在项目各阶段需提交的配置项，并明确基准配置项

基准配置项的变更与完善界定

基准配置项的变更配置需要进行评审，而项目过程中因项目需要更改基准配置项是不可避免的，面对频繁的更改，既要保证更改控制流程不会过分影响项目进度，又要保证更改不会对软件质量造成不例影响，对基准配置项的更改分为变更与完善，采用不同的控制方式，在进度与质量间取得平衡

变更与完善的确定由配置管理负责人和项目经理/项目软件经理共同确认，具体从以下几个方面进行区分：

对软件质量的影响对成本预算的影响对项目进度的影响对项目相关方的影响

影响较大的更改应界定为变更，影响比较小的部分应界定为完善基准配置项完善部分不需要进行评审，但需得到项目经理和配置管理负责人的认可

版本控制

根据内容的不同评审级别要求，文件的版本有着不同的控制规范文件初次生效执行时版本对照

评审活动

公司评审

部门评审

项目组评审

评审级别要求公司级评审部门级评审项目组级评审

注：

完善修改每次版本号提升重大变更每次版本号提升1

-9-

文件类型

源代码和可执行程序的配置规定

项目开发过程中，编码阶段结束后提交的源代码与可执行程序必须配置如果在编码过程中有用户现场开发的情况，则去用户现场前后的源代码与可执行程序必须配置；集成测试结束后提交的源代码与可执行程序必须配置；系统测试结束后提交的源代码与可执行程序必须配置；

产品项目产品释放前如果组织了用户试用，对于根据用户试用反馈修改后的源代码与可执行程序必须配置；

合同项目在实施过程中如果对源代码有修改，每次实施结束后的源代码与可执行程序必须配置

现场开发、实施的相关配置管理规定

确立临时配置管理负责人

项目在客户现场开发或实施时，项目经理/项目软件经理/实施负责人或由其指定具备配置管理经验的项目组成员担当临时配置管理负责人，临时的配置管理负责人执行现场全部的配置管理活动，及时与部门项目管理人员取得联系，定期提交配置活动的基准配置项并承担相应责任

现场开发的配置管理活动

临时配置管理负责人严格按照在公司开发时的配置管理过程执行配置管理工作，尽量每日对源代码进行配置现场需求、设计等基准的变化需统一变更的受理途径，及时进行记录，确保重要修改信息的完整保存

系统集成实施过程中的配置管理活动

配置管理活动的执行过程与在客户现场开发的过程相同重点注意实施中发现问题的处理，发现的以及解决的方法

开发、实施结束后的配置状态的统一归档

项目在客户现场开发或实施结束后，临时配置管理负责人将在现场工作的全部配置管理活动记录上交至项目的配置管理负责人处统一归档进行保存，其在项目配置管理活动中的责任也同时移交

-10-