软件配置管理计划
(Configuration Management Plan)
版本:1.0
(Version: 1.0)
CMMI-CMP-TMP Version 1.0
Date 2006/03/14
IT DEPATTMENT TEAM
文档修订记录
*变化状态:C――创建,A——增加,M——修改,D——删除
文档审批信息
前 言
本计划描述了关于××××项目的SCM组织结构以及贯穿本项目软件生命周期的由SCM组织识别并定义的一系列的软件配置项的实践过程。计划SCM工作必须在项目最开始时进行,和开发整个软件项目计划(SPP)保持一致。软件配置管理计划(SCMP),连同软件质量保证计划(SQAP)和其他可能的特定约束计划都要符合本项目的软件项目计划。SCMP完成之后应该由本项目的项目经理、SQA经理和其他有关人员进行审阅和批准。
目 录
第一章 简介. 2
1.1 文档目的. 2
1.2 适用范围. 2
1.3 背景描述. 2
第二章 参考文件. 2
第三章 资源描述. 3
3.1 所需人员. 3
3.2 所需资源. 4
第四章 SCM活动. 4
4.1 配置项和基线. 4
4.2 控制基线变更. 5
4.3 配置状态信息. 6
4.4 基线建立计划. 6
4.5 基线审计计划. 6
4.6 基线的发布. 7
4.7 构造产品. 7
4.8 软件配置库的管理. 8
第五章 备份. 9
第六章 培训. 9
附 表. 10
《项目基线一览表》. 10
《基线及配置项选择表》. 11
《配置项状态记录》. 12
《产品发布表》. 12
第一章 简介
1.1 文档目的
文档的目的是定义SCM的职责、所需资源以及描述在项目开发以及维护阶段所需要实施的一系列SCM活动。
1.2 适用范围
本计划适用于“××××项目”的软件配置管理活动的制定。
1.3 背景描述
【项目是不同的,但是每个项目都应该有SCM计划,SCM计划的执行应该与开发活动计划相一致,以保证SCM工作范围同开发工作的范围一致。通过识别要置于配置管理之下的配置项和将要建立基线的点,可以确定SCM工作的需求范围和时间。在此背景之下,制定本软件配置管理计划。】
第二章 参考文件
《项目计划》
《软件质量保证计划》
《软件估计书》
《工作产品列表》
《工作拆分结构》
《命名规程》
还可以参见以下文档:
《软件配置管理过程》
《SCM SERVER管理规程》
《命名规程》
《软件配置管理计划制定规程》
第三章 资源描述
【描述项目的 SCM 工作所需的人员、工具和计算机设施等资源。】
3.1 所需人员
3.1.1 SCM小组
本项目的软件配置管理活动都由SCM小组负责执行,SCM领导负责计划和控制软件配置管理过程。
配置负责人:×××
配置人员:×××
3.1.2 配置管理委员会(CCB)
CCB 负责管理项目的软件基线,它的职责主要包括审定软件基线的建立和 CSCIs 及配置项的标识,评审和审定对软件基线的更改,以及审定由软件基线库制造的产品的生成等。
本项目的配置控制委员会(CCB)成员如下:
项目经理:×××(CCB主席)
SCM负责人:×××
SQA负责人:×××
测试负责人:×××
客户代表(高层经理):×××
3.1.3
软件配置的组织结构图
此图仅供参考
3.2 所需资源
3.2.1 计算机设备
【配置服务器的描述,此处所指的服务器是专门为SCM服务的,不包括软件项目的服务器。描述服务器所需要的配置,包括硬盘大小、内存大小、光驱等。】
3.2.2 辅助工具
{配置管理工具,即进行SCM所需要的工具,不包括软件开发过程需要的工具。描述管理工具的名称、发布公司、版本等信息。】
第四章 SCM活动
4.1 配置项和基线
4.1.1 基线选择
参见附表:《项目基线一览表》,选择适用于本项目的基线。
4.1.2 配置项标识
项目开始时,配置人员和项目经理共同选择并确定适用于本项目的配置项,并为配置项标识。列举说明如下表(如果此处不列举,也可以直接参见附表《配置项状态记录》):
4.2 控制基线变更
4.2.1 变更控制
正式变更:
(1)项目组填写并提交《配置变更请求表》CCR
(2)并按照《软件配置管理过程》中的变更控制来处理
(3)配置人员应填写《变更与问题日志》
(4)给定《变更状态报告》发布频度
非正式变更:
(1)项目组填写并提交《产品审批表》
(2)并按照《软件配置管理过程》中的变更控制来处理
(3)配置人员应填写《产品发布报告》
(4)给定《产品发布报告》发布频度
4.2.2 变更控制人员职责
4.2.3 管理问题报告非正式变更是否需要在此处进行描述
软件问题或者是错误(即产品功能与设计与需求不一致),或者是对配置控制下的元素的异常发现(即产品功能与预想的不符),需要更改基线库时,必须填写CCR表,按基线变更流程解决此类问题。
4.3 配置状态信息
【确定项目中配置状态记录的信息、报告和发布频度。在项目的SCM过程中,需要记录配置管理行动,使得每个配置项的内容和状态都清晰明确,并可恢复配置项以前的版本。】
本项目按照下表要求记录和发布配置状态信息:
4.4 基线建立计划
基线是经审查和批准的配置项的集合,在开发周期,基线的建立时间是不同的,会受到不同变更权威的控制。
配置基线建立计划表:
4.5 基线审计计划
在每次主要的软件产品发布之前,必须进行基线审计,验证其完整性。
基线审计计划表:
审计报告格式采用《基线审计报告模板》。
有关审计的要求参见《软件配置管理过程》中的审计部分。
4.6 基线的发布
【基线变更或审计通过之后,由SCM负责人把基线发布给外部客户(如发布运行基线)或内部使用(如为测试而发布)。完成基线发布之后,SCM负责人应该通知所有受影响的人员,使那些经批准可以使用的人利用此发布。】,基线的发布应参照过程描述,进行有关发布。
有关基线发布的要求参见《软件配置管理过程》中的基线发布部分。
有关基线发布的具体内容及说明参见《基线发布报告模板》。
4.7 构造产品
产品的构造是指将源代码进行编译,形成可执行文件,发布给客户的过程。
4.7.1 构造产品的时机
【产品构造一般应在集成或系统测试前,和产品交付客户前进行。】
4.7.2 构造的次数
【一般至少应为3次。分别为集成测试前一次、系统测试前一次、产品交付前一次。】
4.7.3 构造人员
l 【测试前的产品构造由项目经理协助测试人员共同完成;】
l 【产品交付前的构造由项目经理协助配置负责人共同完成。】
4.7.4 对应路径
【因在配置库上无法实现对文件的编译等操作,所以产品的构造必须把相关的文件从配置库上对应到客户端,然后进行产品的构造,构造完成后将产品增加到配置库上,并且交付给发行部门或用于测试。】
4.8.1 构造方法和步骤:
以下内容根据不同的项目方式不同:
l 首先由构造人员在本地机器上(可是构造人员自已的机器也可是其他机器,如其他服务器)为产品建立一个目录。
l 再从配置库上的基线域的代码基线中提取源代码到本地目录中,进行编译(编译的方法需根据开发语言的不同而有所分别,各项目的SCM人员根据实际情况在计划中详细描述)。
l 形成的可执行文件暂存放在本地目录下,批准之后将形成的可执行文件放入到配置库中更新测试基线。
l 从测试基线中提取可执行文件到测试域并进行测试。
l 通过一定的测试,经过CCB批准可以将形成的可执行文件放入到配置库的运行基线下。
l “建立对应目录—>从配置库上提取文件—>编译—>测试—>修改—>重新编译”,其中“编译—>测试—>修改—>重新编译”是一个反复的过程,直至最后测试通过,提交最终产品。
l 最终交付产品前,将要交付的产品对应到本地机器上,用光盘或其他媒体备份,并提交给负责发行的部门。
4.8 软件配置库的管理
规定项目人员对该库的存取权限,格式见下表:
注:对库的存取权限依次为R(只读)、C(修改)、A(增加)、D(删除)四种情况。
第五章 备份
【描述SCM知识库信息备份的频度及备份的保存时间。】
配置库备份记录表:
包括参加的人员、时间、培训内容等。
第六章 培训
对项目组里的SCM人员需要进行培训,以下是SCM培训计划表:
附 表
在制定配置管理计划时可参考以下附表,在进行配置管理活动时可参考使用。
《项目基线一览表》
项目基线一览表
《基线及配置项选择表》
基线及配置项内容
《配置项状态记录》
见《配置项状态记录》模板
《产品发布表》
见《产品发布报告》