项目配置管理计划范本Word文档格式.docx
- 文档编号:14382919
- 上传时间:2022-10-22
- 格式:DOCX
- 页数:19
- 大小:51.18KB
项目配置管理计划范本Word文档格式.docx
《项目配置管理计划范本Word文档格式.docx》由会员分享,可在线阅读,更多相关《项目配置管理计划范本Word文档格式.docx(19页珍藏版)》请在冰豆网上搜索。
修正了几个不足
1.02
增加对受控文件修改后必须增加描述内容
批准人:
日期:
审核人:
这里填写公司地址、联系方式等
1.引言
1.1目的
本文档目的在于机电管理系统性能测试系统进行软件配置管理,提高软件质量,降低软件开发成本。
本文档内容主要参考研发中心相关的ISO程序和制度文档,并在这基础上整理成适合本项目的软件配置管理,为项目经理、配置管理员及相关人员提供日常的配置管理操作步骤。
1.2术语定义
软件配置管理:
简称SCM(SoftwareConfigurationManagement的缩写),是在项目开发中,标识、控制和管理软件变更的一种管理。
配置管理的使用取决于项目规模和复杂性以及风险水平。
软件的规模越大,配置管理就显得越重要。
基线:
(BaseLine)是项目储存库中每个工件版本在特定时期的一个“快照”。
它提供一个正式标准,随后的工作基于此标准,并且只有经过授权后才能变更这个标准。
建立一个初始基线后,以后每次对其进行的变更都将记录为一个差值,直到建成下一个基线。
配置管理员:
项目组中负责配置管理工作的角色,该角色可以兼职。
在某一开发阶段通过评审或某一质量检查点通过审核后,配置管理员负责统一添加或修改相关文档的最新有效版本以及审批人签字。
配置标识:
(ConfigurationIdentification)对软件项目在开发过程中的资源进行标识,以便识别。
配置检查:
(ConfigurationAudit)对软件配置管理过程中的行动进行检查。
1.3参考资料
《研发中心配置管理制度》
《产品的标识与可追溯性程序》
《开发手册》
2.软件配置
2.1软件配置环境
2.1.1服务器软件环境
软件名称
作用
Windowns2000AdvanceServer
操作系统
VisualSourceSafe6.0
配置管理软件
在整个项目过程或产品生命周期中,选择VisualSouceSafe(VSS)作为配置管理工具。
2.1.2硬件环境
名称
规格
说明
网络
局域网
服务器
PC服务器
名称:
fileserver
256M内存
为VSS保留5G独立使用空间
客户机
普通PC机
项目组成员各自的计算机
2.1.3配置管理客户端
项目组成员在各自的计算机安装VSS客户端,项目组成员以分配的帐号访问配置服务器和登录配置管理系统,根据配置管理员设定的用户权限进项配置管理活动。
2.2软件配置项
在本项目的实施过程中,将配置库分为受控配置库和非受控配置库两种
受控配置库
在本项目开发实施的整个过程中,根据不同阶段的配置管理划分11个受控配置目录,只有配置管理员拥有增加和修改的权限,其它用户只有只读的权限。
受控配置库的目录为:
00初始配置
01启动
02需求分析
03设计
04编码
05测试
06安装
07总结
08变更
09项目管理
10环境配置
初始配置库的根目录中包含XXXX项目的配置文件清单,该文档包括本项目开发过程中应该提交的文档的清单,在实际开发过程中,根据实际情况,可以在清单中酌情修改、增加和删除需要提交的文档。
具体内容参见本文3.3的“配置文件清单的维护”。
各个配置目录内应该包含的文档,请参见“XXXX项目配置文件清单.xls”。
非受控配置目录
在本项目开发过程中,设立了非受控配置目录。
设立非受控配置目录的目的是为了统一管理和存放开发过程中产生的临时文档和过程性文档,没有格式及命名上的严格要求,使项目组成员在思考、设计时不受太多的限制和约束,能够更有效地发挥个人能力,符合以人为本的原则。
在项目初期,设立了以下三个目录:
目录名称
用途及说明
个人工作区
用于保存项目成员自己编写的文档,每个项目成员都有自己独立的工作目录
小组工作区
用于保存小组成员写作编写的文档,每个小组都有自己独立的工作目录
文档提交区
作为非受控配置库和受控配置库之间的缓冲,用于提交已经定稿的文档和代码,在评审通过后,再由配置管理员取出并提交到受控配置库中
在根据项目开发过程中,根据实际需要,可以酌情增加非受控配置目录。
2.3配置管理员
在本软件项目开发过程中,项目组必须设立配置管理员,专业(或兼职)负责软件项目开发过程中的软件配置管理工作,保证在项目开发过程中的一些变更管理及文档管理的完整性,顺利地实施项目开发进度。
配置管理员负责制定配置管理计划,检查项目组成员是否正确使用配置库,并督促项目开发计划的实施。
配置管理员还需配合研发中心产品管理部进行项目的配置评审。
评审结束,相关文档的批准人电子签名由批准人签写或经批准人授权配置管理员填写,然后由配置管理员负责签入配置库;
同时,由配置管理员收集配置项审批相关的email文档并签入配置库。
3.软件配置管理计划
关于XXXX项目项目软件配置管理的文档提交计划请参见《XXXX项目配置文件清单.xls》。
关于配置库的日常使用的规定参见附件4《配置库使用规定》。
3.1建立示例配置库
配置管理员在制定完计划后,根据公司建议的配置库建立符合本项目的配置管理库。
配置库建立在VisualSouceSafe上,目录结构可按照示例配置库提供的目录。
对于本项目来说,需要划分多个子系统,因此要在确定子系统的划分后,在不同阶段下分别建立各子系统的配置目录。
XXXX项目其配置管理目录结构如下所示。
配置管理库建立完毕后,可根据配置管理库的人员计划在VisualSouceSafe上建立相应的用户及权限,并将这些用户分发给指定的开发人员或用户。
具体的帐号及权限管理参见附录3《帐号及权限管理》
配置管理员应保管好配置管理工具的管理员权限,项目组中使用配置管理库的成员应该及时更改自己在配置管理工具的缺省设置密码。
3.2配置标识管理
1.文档
根据配置管理计划和配置库中的文档清单,配置管理员要检查需要提交的文档是否都按时提交,文档数目是否符合,文档的标识、命名以及版本等是否符合程序规定。
关于文档的命名请参见附件1《文档命名规定》,文档标识及版本参见附件2《文档编码规范》
2.程序
所有属于该项目的程序、分程序、模块和程序单元,都要按照由项目组和配置管理员制订的软件系统的命名约定的规定来标识。
要求所有模块的源代码都需记录模块编号,且模块编号在整个系统中是唯一的。
模块编号在系统设计完成之后,由项目组和配置管理员共同根据系统设计进行编制。
3.基线
所有属于本项目及其各子系统的各类基线,首先要按照计划书、软件需求规格说明书、软件项目详细分析设计说明书的规定确定其技术内容,在整个软件项目开发过程中定义以下两类基线:
文档基线:
本项目的文档基线的定义以里程碑的定义为准,将到达各阶段的里程碑时的文档作为基线,具体里程碑的定义参见第4节“里程碑”。
产品基线:
产品基线包含两个,一个是系统上线时,一个是系统经过客户验证测试时,基线包含那时的所有程序代码和文档。
配置管理员负责在项目开发的每一个里程碑处、每一个阶段性的版本发布时负责为整个配置库设立书签,划定配置管理基线,并以文档的方式记录下这些书签的定义。
3.3配置库控制
权限控制
配置管理员根据附录3《帐号及权限管理》设置和调整项目组成员对配置项的权限。
配置库的控制
在项目开发和实施的整个过程中,配置管理员应根据配置管理计划及管理规则对配置库应进行管理和控制。
配置管理员负责检查项目组成员使用配置库是否正确。
包括是否及时检入最新版本、是否添加了注释、是否及时更改配置状态,是否存在项目组成员修改了不属于自己负责的配置项,项目组成员是否完成了自己负责的配置项的检入,测试版本的构造是否从配置库中取出等。
建立软件库
在项目的各个开发阶段,应建立起各阶段各子系统的软件开发库(软件开发工作区),同时建立起想对应的有关该系统及其子系统的软件受控库。
在每个阶段结束或里程碑,需让各子系统提交相关的产品并送入软件受控库,由配置管理员统一管理,以后再有对产品的变更需求,应按照正常的变更程序来控制并检查相关的变更文档。
当全部开发工作结束,需建立起软件产品库,将所有可交付的产品都送入软件产品库。
软件配置更改
软件配置的更改管理适用于全部项目的所有文档和代码,其中包括整个项目的各个运行软件,也包括为项目专门开发的支持软件。
●对该项目各个子系统及其专用支持软件的基线及其集成系统的任何修改,必须得到项目负责人的批准并在本项目软件质量管理专员处备案才能进行配置更改;
●更改完成后的文档和代码等,需得到项目负责人认可,提交给配置管理员后,由配置管理员签入受控配置库;
●受控配置库中的文档,在文档末尾必须有修改记录部分,包括修改人、修改日期、修改内容等项,每次对于受控配置库中文档的修改,必须填写这些项。
配置文件清单的维护
●配置文件清单的维护由配置管理员维护;
●项目初期,配置管理员与项目组成员一起对开发过程中可能产生的文档的进行预计,并在配置文件清单中列出这些文档及其大致的计划提交时间;
●在实际开发过程中,文档提交可能会产生一些变化,如新增某些文档、原计划的一些文档不再单独产生、文档计划提交日期的变更等,项目组应该及时通知配置管理员,由配置管理员及时更改配置文件清单中的相应项。
3.4配置的检查和评审
配置的检查和评审可通过研发中心配置管理制度的审核内容来进行检查。
相关的审核内容如下表:
审核分类
审核内容
检查情况
发布审核
发布文档是否清楚地定义发布的范围,包括应被纳入的更改请求?
所有已知缺陷/毛病(bug)是否已文档化?
是否有适当的文档,它标识重建该发布所需的环境(编译器版本、OS版本、compilationflags,等等)?
是否有适当的文档,它说明构成该发布的成分及成分的版本?
发布的所有项是否彼此同步(在时间上一致)?
是否采用正确存储库中的正确成分的正确版本生成发布?
存储库/配置项审核
存储库是否按SCM计划定义?
项是否已经进入正确的库?
是否按SCM计划中规定的命名约定项命名?
是否按照SCM计划,规定项的版本号?
是否按照SCM计划中规定的事件已经将所有项入库?
例如:
测试完成、客户的评审意见已采纳
项是否有所要求的文档以识别项、版本和更改历史?
更改实施审核
是否全部所要求的更改请求均已结束?
是否更改请求标识出全部拟更改的项?
更改请求中所标识的全部要更改的项均已更改,被QC和在所要求的QC后入库?
是否可能在项的任何两个版本中间区分更改?
项的文档是否足够,能向后追踪更改到相应的更改请求?
是否有恰当方法能回到以前的版本?
审核的其他方面
是否对库作了恰当的备份?
是否已测试过从备份中恢复?
在群组成员的工作目录中是否有任何未经许可的成分?
是否有恰当的保密/批准手续以保证只有经授权的群组成员才能进行入库/出库?
配置管理员应配合研发中心产品管理部定期对项目进行配置管理的审核。
在审核过程中,提供所需要的配置管理计划及相关资料,在项目开发结束后,需提交所有关于项目的软件配置库
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 配置管理 计划 范本