配置管理计划
1. 导言
软件项目进行过程中面临的一个主要问题是持续不断的变化,变化是多方面的,而配置管理是有效管理变化的手段,软件配置管理(SCM)是一套规范高效的软件开发管理的方法,同时也是提高软件质量的重要手段,它帮助开发团队对软件开发过程中进行有效的变更控制,高效地开发高质量的软件。通过制定配置管理计划确定软件配置管理的解决方案,并做为在整个开发过程中配置管理活动的依据进行使用和维护。
2. 组织及职责
(1) 根据《项目计划》中的角色分配,确定配置管理者,SCCB成员。
(2) 项目经理是SCCB的负责人。
(3) 配置管理的角色和职责见表1。
表1 配置管理角色指责表
l
3. 配置管理环境
由于本项目属于中小型项目,工期不是很长,经费不多,由于CVS简单易用、功能强大、跨平台、支持并发版本,而且免费,所以选用CVS作为配置管理工具。
3.1目录结构
本项目配置库的目录结构见表2。
表2 配置库的目录结构
3.2用户权限
本项目配置库的用户及权限如表3。
表3 配置库的用户权限
4. 软件配置管理活动
4.1配置项标识
4.11命名规范
命名规范适用于过程文档生存期中各个阶段的计划、需求、设计、代码、测试、手册等文件。
本项目文件命名规范由五个字段组成,从左到右依次为:公司、项目、类型、编好和版本号,如图1所示。字段间用一横线(—)分隔。
图1 文档命名规范
4.1.2主要配置项
本项目主要配置项如表4。
表4 配置项列表
4.1.3项目基线
基线管理由项目执行人确认,SCCB授权,由配置管理员执行。项目基线如表5所示。
表5 基线发布计划
4.1.4配置项的版本管理
配置项可能包含的分支从逻辑上可以划分为4个不同功能的分支,让它们分别对应4类工作空间。
l 主干分支
l 私有分支
l 小组分支
l 集成分支
4.2变更管理
变更管理流程:
1) 由请求者提交变更请求,变更控制委员会召开复审会议变更请求进行复审,以确认该请求是否为有效请求。典型的变更请求管理有需求变更管理、缺陷追踪等。
2) 配置管理者收到基线修改请求后,在配置库中生成与此配置项有关的波及关系表。
3) 配置管理者将基线波及关系表提交给SCCB,由SCCB确定是否需要修改,如果需要修改,SCCB应根据波及关系表,确定修改的具体文件,并在波及分析表中表示出来。
4) 配置管理者按照出库程序从配置库中提取出需要修改的文件。
5) 项目人员将修改后的文件提交给配置管理者。
6) 配置管理者将修改后的配置项按入库程序放入配置库。
7) 配置管理者按SCCB标识出的修改文件,由波及关系表生成基线变更记录表,并按入库程序放入配置库。
4.3配置状态统计
利用配置状态统计可以记录和跟踪配置项的改变。状态统计可用于评估项目风险,在开发过程中跟踪更改,并且提供统计数据以确保所有必须的更改被执行。为跟踪工作产品基线,配置管理者需收集下列信息:
l 基线类型
l 工作产品名称
l 配置项名称
l 版本号
l 更改日期/时间
l 更改请求列表
l 需要更改的配置项
l 当前状态
l 当前状态发生的日期
项目小组没周提交配置清单及其当前版本。
配置管理人员每半个月提交变更请求的状态统计。
第二篇:配置管理计划模板V1.0
软件配置管理计划
(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培训计划表:
附 表
在制定配置管理计划时可参考以下附表,在进行配置管理活动时可参考使用。
《项目基线一览表》
项目基线一览表
《基线及配置项选择表》
基线及配置项内容
《配置项状态记录》
见《配置项状态记录》模板
《产品发布表》
见《产品发布报告》