配置管理规范.docx
- 文档编号:3096229
- 上传时间:2023-05-05
- 格式:DOCX
- 页数:12
- 大小:72.82KB
配置管理规范.docx
《配置管理规范.docx》由会员分享,可在线阅读,更多相关《配置管理规范.docx(12页珍藏版)》请在冰点文库上搜索。
配置管理规范
配置管理规范
文件控制
文档编号
版本号
V1.0
分册名称
第册/共册
总页数
正文
附录
编制
审批
生效日期
修改变更记录:
更改条款及内容
更改人
审批人
更改日期
目录
1目的2
2范围2
3术语2
4职责2
5程序3
5.1配置管理中的阶段划分3
5.2配置管理策划与计划4
5.3配置库建立4
5.3.1配置管理工具4
5.3.2配置库结构4
5.3.3配置库存取权限控制4
5.3.4配置库文件存取时间控制5
5.4配置项标识5
5.5配置控制5
5.5.1配置项和软件基准的存储控制5
5.5.2配置库结构层次的变更6
5.5.3非基准配置项的变更控制6
5.5.4基准配置项的变更控制6
5.5.5变更信息沟通7
5.6配置状态跟踪7
5.7配置审计7
5.7.1配置审计的目的与时机7
5.7.2配置审计工作准备7
5.8配置管理8
5.8.1配置库结构层次和内容8
5.8.2基准配置项的变更与完善界定8
5.8.3版本控制9
5.8.4源代码和可执行程序的配置规定9
5.8.5现场开发、实施的相关配置管理规定9
6相关文件10
7记录10
1目的
本文件规定了项目进行过程中配置管理活动的流程以及组织对配置管理的具体要求。
公司项目过程中的配置活动必须以本文件的规定进行实施配置管理。
2范围
本文件适用于公司项目全过程中的软件配置活动,包括项目的配置计划,配置评审,配置实施,配置变更等等。
3术语
配置项:
项目开发或系统集成实施过程中所需要或所产生的软件、硬件、工具、释放产品、文档,包括基准配置项与非基准配置项。
基准配置项:
通过正式评审成为下一步开发或实施基础的配置项,只有通过规范要求的变更控制程序才能被更改。
更改:
配置项的变更与更改统称为更改。
CAR(ConfigurationAuditReport):
配置审计报告
4职责
――配置管理负责人(CML)
负责制定配置管理计划,并在项目进行过程中按照计划执行配置管理活动,实时更新项目的“配置状态报告”和《配置库结构层次图》,并向所有受影响的项目组和个儿通报当前配置管理状态。
――软件质量保证负责人(SQAL)
负责根据《软件质量保证计划》的安排实时跟踪项目软件配置管理的实施情况;参与配置审计并跟踪纠正/预防措施的执行情况直到问题关闭。
――项目经理/项目软件经理(PM/PSM)
负责协调配置管理活动实施,协同配置管理负责人管理项目配置库;参与配置审计,会同项目相关人员实施确定的纠正/预防措施。
5程序
5.1配置管理中的阶段划分
根据配置管理过程中不同时期不同侧重点,配置管理活动划分为以下几个阶段:
(1)配置管理策划阶段;
(2)配置管理实施阶段;
(3)配置库结构层次变更;
(4)软件基准变更;
(5)配置审计;
(6)配置备份
5.2配置管理策划与计划
通常情况下,在项目产品策划阶段制定配置管理计划。
配置管理计划一般包含人员职责,配置管理软硬件资源描述,配置项描述,基准配置项描述,项目成员的操作权限划分以及备份方案等。
配置管理计划的制定由软件配置管理负责人在开发策划阶段根据项目经理/项目软件经理的任务分解及进度安排情况制定。
具体内容可参照《配置管理计划》模板和《配置库结构层次图》。
5.3配置库建立
5.3.1配置管理工具
常见的配置管理工具有微软公司的Vss。
公司常规软件项目产品开发所使用的开发工具为Vs2005和Vs2010。
5.3.2配置库结构
项目立项后,配置管理负责人即可根据评审后的《配置库层次结构图》建立项目配置库,为保证配置项目录的顺序可在目录名前加上序号进行确认。
5.3.3配置库存取权限控制
配置管理负责人按照项目计划并和项目经理充分沟通的情况下来设定项目组及有关人员对配置库的存取控制,并且负责在项目进行中维护配置库的存取权限。
5.3.4配置库文件存取时间控制
对配置库进行操作的人员,对公共部分的文件的时间间隔不能过长,以方便其他人进行共享操作。
通常情况下在配置管理策划过程中应明确项目文档、需实时更新的各种记录以及源代码、可执行程序的操作间隔时间,以保证查阅人员可以及时从配置库中获取最新信息。
配置审计过程中可将文件存取时间作为审计内容之一。
5.4配置项标识
开发过程中要标识的配置项主要包括以下几部分:
1)开发环境与测试环境:
软件工具、硬件设备等;
2)开发工具:
自动设计工具、测试工具、维护工具等;
3)项目文档:
立项建议报告、可行性分析报告、项目计划、软件需求规格说明书、任务分解书、质量保证计划、系统设计报告、测试文档、技术报告、项目总结报告、系统集成方案、交付和安装记录等;
4)质量记录:
各类评审记录和表格文档,如《项目任务书》、《变更控制报告》、《软件需求变更记录》等;
5)提交产品:
源代码、可执行程序、联机帮助、用户手册等。
标识要求
1)在开发与实施过程中项目组人员提交的文档,按照《标识规范》进行标识;
2)合同有明确标识和追踪要求时,按合同要求进行标识,以保证满足合同的追踪要求;
3)外购产品使用原有标识;
4)在《标识规范》中没有明确要求的项目进行过程中形成的中间文档,在纳入配置前应加以唯一标识,文档类别代号可自行采用合适的英文缩写。
5.5配置控制
5.5.1配置项和软件基准的存储控制
配置项的存储
在项目立项后,投标书、方案等市场前期策划的文档及相应评审记录由配置管理负责人从市场人员处获得放入市场前期策划阶段子目录下进行保存;启动阶段的技术和表格文档及相应的评审记录等由项目组和配置管理负责人放在配置库的启动阶段子目录下进行管理和控制;进入实施阶段,项目组人员按照配置管理计划及时提交配置项,通过评审的配置项及评审记录,放在项目组的配置库里,同时配置管理负责人进行备份。
项目基准配置项的建立
项目组人员提交的配置项按照《评审规程》进行正式评审通过后即可作为基准配置项,并由配置管理负责人将成为基准的配置项及相应的评审记录放入配置库中,以便进行管理和控制;同时部门项目管理人员及时在部门服务器中对基准配置项进行备份。
基准建立后,需将基准内容及时在“配置状态记录”中进行记录并通知所有受影响的部门、项目组和个人。
5.5.2基准配置项的变更控制
变更请求的提出
客户或开发部门要求变更已建立的基准配置项、重要的项目组成员、重要的项目资源(环境、工具等)时,一定要填写《变更控制报告》。
填写《变更控制报告》时,要求进行变更请求说明和变更评估,变更评估时要考虑以下几种情况:
1)一般情况下,变更评估要考虑变更对其它配置项尤其是对当前基准配置项的影响及变更的效果;
2)如果变更较大,还要评估变更对项目进度、成本和质量的影响;
3)如果变更是为了增加需求,还要将报价单交给客户审批。
变更请求的审批与实施
按照《评审规程》的要求,部门项目管理人员组织对本次变更的评审,建议的变更请求被批准,由部门项目管理人员负责跟踪相应变更的实施。
5.5.3变更信息沟通
配置库中任何信息的变更实施结束后,配置管理负责人在将对配置库中内容进行调整、更新《配置库结构层次图》和相关“配置状态记录”的同时必须将变更的信息通知给所有受影响的部门、项目组和个人。
5.6配置状态跟踪
配置库可以通过《配置库结构层次图》和《项目配置状态报告》进行状态跟踪,要求《配置库结构层次图》和《项目配置状态报告》始终保持最新状态。
5.7配置审计
5.7.1配置审计的目的与时机
配置审计的目的在于力图发现和报告项目配置管理工作中的缺陷并跟踪缺陷的解决情况。
配置审计的内容如下:
(1)验证基准配置项内容的完整性和正确性;
(2)配置管理系统的结构和设施;
(3)配置管理工作是否遵循组织程序文件;
配置审计工作有项目管理人员组织并实施,并出具《配置审计报告》,参见《配置审计报告》模板。
配置审计的时机分为两种策略:
一种是定期进行配置审计;另一种通常为项目进入到总结阶段或每次基准配置项发生重大变更时。
5.7.2配置审计工作准备
◆确认审计组人员
审计组成员包括配置管理负责人、项目经理/项目软件经理、开发人员或实施工程师以及项目的软件质量保证负责人。
1)项目管理人员:
负责审计工作准备和审计实施,协助项目的质量保证负责人L跟踪来自审计的纠正/预防措施直到关闭。
编写“配置审计报告”,提交给项目的配置管理负责人并保存在项目配置库中;
2)配置管理负责人:
对于审计中发现的配置缺陷,采取必要的纠正措施;
3)项目经理/项目软件经理:
对于审计中发现的软件工程缺陷,采取必要的纠正措施;
4)开发人员或实施工程师:
必要时一些开发人员或实施工程师参与审计组,提供相关的技术支持;
5)软件质量保证负责人:
参与配置审计并跟踪来自审计的纠正/预防措施直到关闭。
◆确认审计日程安排
◆准备配置审计检查表,参照《配置审计报告》模板
5.8配置管理
5.8.1配置库结构层次和内容
根据《配置库结构层次》图中提供的软件生命周期划分的通用目录结构结合项目的具体特点做相应适当的调整。
按项目计划和阶段进度表中计划提交的“阶段成果”内容,在配置管理策划时确定在项目各阶段需提交的配置项,并明确基准配置项。
5.8.2基准配置项的变更与完善界定
基准配置项的变更配置需要进行评审,而项目过程中因项目需要更改基准配置项是不可避免的,面对频繁的更改,既要保证更改控制流程不会过分影响项目进度,又要保证更改不会对软件质量造成不例影响,对基准配置项的更改分为变更与完善,采用不同的控制方式,在进度与质量间取得平衡。
变更与完善的确定由配置管理负责人和项目经理/项目软件经理共同确认,具体从以下几个方面进行区分:
◆对软件质量的影响
◆对成本预算的影响
◆对项目进度的影响
◆对项目相关方的影响
影响较大的更改应界定为变更,影响比较小的部分应界定为完善。
基准配置项完善部分不需要进行评审,但需得到项目经理和配置管理负责人的认可。
5.8.3版本控制
根据内容的不同评审级别要求,文件的版本有着不同的控制规范。
文件初次生效执行时版本对照
评审活动
评审级别要求
公司评审
部门评审
项目组评审
公司级评审
1.0
0.7
部门级评审
1.0
0.7
项目组级评审
1.0
注:
完善修改每次版本号提升0.1重大变更每次版本号提升1
5.8.4源代码和可执行程序的配置规定
(1)项目开发过程中,编码阶段结束后提交的源代码与可执行程序必须配置。
如果在编码过程中有用户现场开发的情况,则去用户现场前后的源代码与可执行程序必须配置;
(2)集成测试结束后提交的源代码与可执行程序必须配置;
(3)系统测试结束后提交的源代码与可执行程序必须配置;
(4)产品项目产品释放前如果组织了用户试用,对于根据用户试用反馈修改后的源代码与可执行程序必须配置;
(5)合同项目在实施过程中如果对源代码有修改,每次实施结束后的源代码与可执行程序必须配置
5.8.5现场开发、实施的相关配置管理规定
确立临时配置管理负责人
项目在客户现场开发或实施时,项目经理/项目软件经理/实施负责人或由其指定具备配置管理经验的项目组成员担当临时配置管理负责人,临时的配置管理负责人执行现场全部的配置管理活动,及时与部门项目管理人员取得联系,定期提交配置活动的基准配置项并承担相应责任。
现场开发的配置管理活动
临时配置管理负责人严格按照在公司开发时的配置管理过程执行配置管理工作,尽量每日对源代码进行配置。
现场需求、设计等基准的变化需统一变更的受理途径,及时进行记录,确保重要修改信息的完整保存。
系统集成实施过程中的配置管理活动
配置管理活动的执行过程与在客户现场开发的过程相同。
重点注意实施中发现问题的处理,发现的BUG以及解决的方法。
开发、实施结束后的配置状态的统一归档
项目在客户现场开发或实施结束后,临时配置管理负责人将在现场工作的全部配置管理活动记录上交至项目的配置管理负责人处统一归档进行保存,其在项目配置管理活动中的责任也同时移交。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 配置管理 规范