《项目配置管理计划范本培训讲学》由会员分享，可在线阅读，更多相关《项目配置管理计划范本培训讲学（21页珍藏版）》请在金锄头文库上搜索。
1、机电管理系统性能测试系统配置管理计划1这里填写公司名称文档编号：XXXXXXXX-XXX-XXX版 本 号：1.00产品名称:机电管理系统性能测试系统文档名称:配置管理计划版本修改内容描述修改人日期备注1.00第一版1.01修正了几个不足1.02增加对受控文件修改后必须增加描述内容批准人： 日期：审核人： 日期：这里填写公司地址、联系方式等 XXXX项目配置管理计划 XXXX公司目录1. 引言11.1 目的11.2 术语定义11.3 参考资料12. 软件配置22.1 软件配置环境22.2 软件配置项22.3 配置管理员33. 软件配置管理计划43.1 建立示例配置库43.2 配置标识管理63.
2、3 配置库控制73.4 配置的检查和评审83.5 配置库的备份93.6 配置管理计划的修订93.7 配置管理计划附属文档94. 里程碑11附录1 文档命名规定121、受控配置库文件命名规则122、非受控配置库文件命名规则123、提交文档文件命名规则12附录2 文档编码规范13附录3 帐号及权限管理14附录4 配置库使用规定16文档修改记录171 XXXX项目配置管理计划 XXXX公司1. 引言1.1 目的 本文档目的在于机电管理系统性能测试系统进行软件配置管理，提高软件质量，降低软件开发成本。本文档内容主要参考研发中心相关的ISO程序和制度文档，并在这基础上整理成适合本项目的软件配置管理，为项
3、目经理、配置管理员及相关人员提供日常的配置管理操作步骤。 1.2 术语定义软件配置管理：简称SCM（Software Configuration Management的缩写），是在项目开发中，标识、控制和管理软件变更的一种管理。配置管理的使用取决于项目规模和复杂性以及风险水平。软件的规模越大，配置管理就显得越重要。基线：(BaseLine) 是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。配置管理员：项目组中负责配置管理工作的角色，
4、该角色可以兼职。在某一开发阶段通过评审或某一质量检查点通过审核后，配置管理员负责统一添加或修改相关文档的最新有效版本以及审批人签字。配置标识：（Configuration Identification）对软件项目在开发过程中的资源进行标识，以便识别。配置检查：（Configuration Audit）对软件配置管理过程中的行动进行检查。1.3 参考资料 研发中心配置管理制度产品的标识与可追溯性程序开发手册12. 软件配置 2.1 软件配置环境2.1.1 服务器软件环境软件名称作用Windowns 2000 Advance Server操作系统Visual Source Safe 6.0配置管理
5、软件在整个项目过程或产品生命周期中,选择Visual Souce Safe(VSS)作为配置管理工具。2.1.2 硬件环境名称规格说明网络局域网服务器PC服务器名称：fileserver256 M 内存为VSS保留5G独立使用空间客户机普通PC机项目组成员各自的计算机2.1.3配置管理客户端项目组成员在各自的计算机安装VSS客户端，项目组成员以分配的帐号访问配置服务器和登录配置管理系统，根据配置管理员设定的用户权限进项配置管理活动。2.2 软件配置项在本项目的实施过程中，将配置库分为受控配置库和非受控配置库两种受控配置库在本项目开发实施的整个过程中，根据不同阶段的配置管理划分11个受控配置目录
6、，只有配置管理员拥有增加和修改的权限，其它用户只有只读的权限。受控配置库的目录为：00初始配置01启动02需求分析03设计04编码05测试06安装07总结08变更09项目管理10环境配置初始配置库的根目录中包含XXXX项目的配置文件清单，该文档包括本项目开发过程中应该提交的文档的清单，在实际开发过程中，根据实际情况，可以在清单中酌情修改、增加和删除需要提交的文档。具体内容参见本文3.3的“配置文件清单的维护”。各个配置目录内应该包含的文档，请参见“XXXX项目配置文件清单.xls”。非受控配置目录在本项目开发过程中，设立了非受控配置目录。设立非受控配置目录的目的是为了统一管理和存放开发过程中产
7、生的临时文档和过程性文档，没有格式及命名上的严格要求，使项目组成员在思考、设计时不受太多的限制和约束，能够更有效地发挥个人能力，符合以人为本的原则。在项目初期，设立了以下三个目录：目录名称用途及说明个人工作区用于保存项目成员自己编写的文档，每个项目成员都有自己独立的工作目录小组工作区用于保存小组成员写作编写的文档，每个小组都有自己独立的工作目录文档提交区作为非受控配置库和受控配置库之间的缓冲，用于提交已经定稿的文档和代码，在评审通过后，再由配置管理员取出并提交到受控配置库中在根据项目开发过程中，根据实际需要，可以酌情增加非受控配置目录。2.3 配置管理员在本软件项目开发过程中，项目组必须设立配
8、置管理员，专业（或兼职）负责软件项目开发过程中的软件配置管理工作，保证在项目开发过程中的一些变更管理及文档管理的完整性，顺利地实施项目开发进度。配置管理员负责制定配置管理计划，检查项目组成员是否正确使用配置库，并督促项目开发计划的实施。配置管理员还需配合研发中心产品管理部进行项目的配置评审。评审结束，相关文档的批准人电子签名由批准人签写或经批准人授权配置管理员填写，然后由配置管理员负责签入配置库；同时，由配置管理员收集配置项审批相关的email文档并签入配置库。3. 软件配置管理计划关于XXXX项目项目软件配置管理的文档提交计划请参见XXXX项目配置文件清单.xls。关于配置库的日常使用的规定
9、参见附件4配置库使用规定。3.1 建立示例配置库配置管理员在制定完计划后，根据公司建议的配置库建立符合本项目的配置管理库。配置库建立在Visual Souce Safe上，目录结构可按照示例配置库提供的目录。对于本项目来说，需要划分多个子系统，因此要在确定子系统的划分后，在不同阶段下分别建立各子系统的配置目录。XXXX项目其配置管理目录结构如下所示。配置管理库建立完毕后，可根据配置管理库的人员计划在Visual Souce Safe上建立相应的用户及权限，并将这些用户分发给指定的开发人员或用户。具体的帐号及权限管理参见附录 3 帐号及权限管理配置管理员应保管好配置管理工具的管理员权限，项目组中
10、使用配置管理库的成员应该及时更改自己在配置管理工具的缺省设置密码。3.2 配置标识管理1文档根据配置管理计划和配置库中的文档清单，配置管理员要检查需要提交的文档是否都按时提交，文档数目是否符合，文档的标识、命名以及版本等是否符合程序规定。关于文档的命名请参见附件 1 文档命名规定，文档标识及版本参见附件 2文档编码规范2程序所有属于该项目的程序、分程序、模块和程序单元，都要按照由项目组和配置管理员制订的软件系统的命名约定的规定来标识。要求所有模块的源代码都需记录模块编号，且模块编号在整个系统中是唯一的。模块编号在系统设计完成之后，由项目组和配置管理员共同根据系统设计进行编制。3基线所有属于本项
11、目及其各子系统的各类基线，首先要按照计划书、软件需求规格说明书、软件项目详细分析设计说明书的规定确定其技术内容，在整个软件项目开发过程中定义以下两类基线：文档基线：本项目的文档基线的定义以里程碑的定义为准，将到达各阶段的里程碑时的文档作为基线，具体里程碑的定义参见第4节“里程碑”。产品基线：产品基线包含两个，一个是系统上线时，一个是系统经过客户验证测试时，基线包含那时的所有程序代码和文档。配置管理员负责在项目开发的每一个里程碑处、每一个阶段性的版本发布时负责为整个配置库设立书签，划定配置管理基线，并以文档的方式记录下这些书签的定义。3.3 配置库控制权限控制配置管理员根据附录 3帐号及权限管理
12、设置和调整项目组成员对配置项的权限。配置库的控制在项目开发和实施的整个过程中，配置管理员应根据配置管理计划及管理规则对配置库应进行管理和控制。配置管理员负责检查项目组成员使用配置库是否正确。包括是否及时检入最新版本、是否添加了注释、是否及时更改配置状态，是否存在项目组成员修改了不属于自己负责的配置项，项目组成员是否完成了自己负责的配置项的检入，测试版本的构造是否从配置库中取出等。建立软件库在项目的各个开发阶段，应建立起各阶段各子系统的软件开发库（软件开发工作区），同时建立起想对应的有关该系统及其子系统的软件受控库。在每个阶段结束或里程碑，需让各子系统提交相关的产品并送入软件受控库，由配置管理员
13、统一管理，以后再有对产品的变更需求，应按照正常的变更程序来控制并检查相关的变更文档。当全部开发工作结束，需建立起软件产品库，将所有可交付的产品都送入软件产品库。软件配置更改软件配置的更改管理适用于全部项目的所有文档和代码，其中包括整个项目的各个运行软件，也包括为项目专门开发的支持软件。l 对该项目各个子系统及其专用支持软件的基线及其集成系统的任何修改，必须得到项目负责人的批准并在本项目软件质量管理专员处备案才能进行配置更改；l 更改完成后的文档和代码等，需得到项目负责人认可，提交给配置管理员后，由配置管理员签入受控配置库；l 受控配置库中的文档，在文档末尾必须有修改记录部分，包括修改人、修改日
14、期、修改内容等项，每次对于受控配置库中文档的修改，必须填写这些项。配置文件清单的维护l 配置文件清单的维护由配置管理员维护；l 项目初期，配置管理员与项目组成员一起对开发过程中可能产生的文档的进行预计，并在配置文件清单中列出这些文档及其大致的计划提交时间；l 在实际开发过程中，文档提交可能会产生一些变化，如新增某些文档、原计划的一些文档不再单独产生、文档计划提交日期的变更等，项目组应该及时通知配置管理员，由配置管理员及时更改配置文件清单中的相应项。3.4 配置的检查和评审配置的检查和评审可通过研发中心配置管理制度的审核内容来进行检查。相关的审核内容如下表：审核分类审核内容检查情况发布审核发布文档是否清楚地定义发布的范围，包括应被纳入的更改请求？所有已知缺陷/毛病(bug)是否已文档化？是否有适当的文档，它标识重建该发布所需的环境（编译器版本、OS版本、compilation flags，等等）？是否有适当的文档，它说明构成
