配置管理制度分析

1、信息系统配置管理规范信息系统配置管理规范目录1 概述31.1.目的31.2.范围31.3.术语31.4.角色与职责32 配置管理范围43 项目配置库建立与使用43.1 项目配置库建立43.2 项目配置库使用44 权限变更55 配置库安全56 配置库使用规范6附录一：配置项命名规则7附录二：配置库目录结构管理规定8附录三：基线库产品清单91 概述1.1. 目的为了保证XXXX研发项目文件的安全性、机密性；保证信息系统的完整性、有效性及可追溯性，以及加强研发项目的协同能力，特制订本制度。1.2. 范围适用于本行所有信息系统。1.3. 术语 术语描述信息系统配置管理是在信息系统项目开发中，标识、控制

2、和管理软件变更的一种管理。基线是项目开发库中每个文件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。开发库（devlib）存放开发过程中需要保留的各种信息，供开发人员个人专用。开发人员对其具有编辑、修改、删除等操作权限。基线库（baselib）开发库中产品经过测试小组测试后，行成一个稳定的版本，由配置管理员从开发库中将该版本提取出来，行成一个新的版本。以后的版本更新将在此基础上进行更新。所有人员对基线库的最大权限只能为只读权限。1.4. 角色与职责角色职

3、责项目经理确定配置项、确定配置库目录权限；审查配置库变更；项目开发过程中，监督配置库使用情况；员工离职时，配置库归档完整性审核。项目小组根据配置管理制度规范，进行配置库的日常使用。配置管理员负责配置库的建立、权限设置、负责培训开发人员使用配置管理工具、对配置库使用情况进行管理和监督、建立配置库基线；定期备份配置库；建立和完善配置管理制度。2 配置管理范围研发项目过程中产生的所有文档，包括：研发项目管理文档、研发设计及技术文档、源代码、可执行程序，工具及相关资料等。u 项目文档主要：立项书、项目计划、例会会议记录及项目过程中管理类文档等。u 设计及技术文档主要：需求，需求分析报告、概要设计说明书

4、、详细设计说明书、数据库表结构、测试文档、使用说明书、技术说明书等。u 工具及其相关资料：开发或测试过程中的工具，以及其使用文档等，如觉得有必要也纳入配置库的管理。3 项目配置库建立与使用3.1 项目配置库建立1. 项目立项时，由项目经理申请建立项目配置库（附录二X配置库申请单）2. 配置管理员与项目经理根据配置管理的流程确定配置管理计划。3. 配置项：项目经理与配置管理员共同确认研发项目的配置库目录结构，并建立配置库目录结构；所建配置库目录结构必需按本文规定目录结构执行（目录结构参考附录二）。4. 项目小组：项目经理提供项目小组成员名单及联系方式，配置库权限清单（内容应包括员工姓名、目录权限

5、等）5. 权限分配：配置管理员为相关人员的设置配置权限。配置库权限设置完成之后，由配置管理员将配置库名称、访问路径、访问权限等信息以邮件方式通知各相关人员；配置库使用人员以各自的用户名和密码进行访问配置库。6. 配置库密码只能在服务器上设置，如配置库使用人员密码遗忘或需要修改，可以与配置管理员取得联系，进行修改密码。3.2 项目配置库使用1. 配置库目录说明配置库基本结构如“附录二”所示，以项目名称作为一级目录，二级目录包括：devlib、testlib、PMlib、baselib： “devlib”：项目小组日常研发活动区；该目录包含docs（设计文档）、src（代码）目录。“PMlib”：

6、放项目管理文档，为科研处项目管理部门和项目经理使用；“testlib”：项目小组在此目录下记录项目测试中的文档，如内部测试、中试申请、中试报告、评审纪要。“baselib”：仅放置PLM发布版本，项目经理具有读权限；开发人员在该目录下不允许对源代码等文件进行修改。2. 配置库使用说明a) 项目开发小级在“devlib”进行日常开发活动。b) 项目经理在“PMlib”中记录项目管理文档。c) 项目进行到中试测试阶段，由项目经理通过“branch/tag”（中文为：“分支/标记”）的方式，将“devlib”在“testlib/测试版本”中建立版本分支。再由项目管理员从此库中“导出”，并根据PLM入

7、库相关的规定，通过PLM相关流程进行中试测试。中试测试过程中产生的文档记录在“testlib”相关目录中。d) 中试测试合格，科研处在进行对项目发布前，将“testlib/测试版本”中建立的版本分支在“baselib”建立发布版本分支。4 权限变更使用配置库的过程中需要变更配置库管理权限，由项目经理填写配置库权限变更单，并以邮件方式通知配置管理员，配置管理员变更之后，将变更结果以电子邮件方式通知受影响的人员、项目经理及其相关人员。配置管理员根据配置库权限变更频率，每隔一段时间将配置库权限清单与各项目经理进行审核确认。5 配置库安全l 配置服务器系统安全：配置管理员进行服务器的日常管理与维护，做

8、好防入侵、防病毒工作。l 配置库备份：配置管理员定期做好配置库的备份，以防意外，避免给公司带来严重的损失。配置管理员每日进行硬盘备份一次，每周进行异地硬盘备份一次，每月进行光盘备份一次,备份后的光盘标记上备份日期并附上内容清单，移交公司相关部门保管。 6 配置库使用规范1. 各项目必需使用科研处提供的配置管理环境建立配置管理库。2. 配置管理员由科研处任命，科研处负责进行配置管理的管理工作。3. 所有立项的科研项目，都必须申请建立配置库。开发过程中所有文档和代码必须纳入配置库管理。4. 配置库服务器密码只有配置管理员及科研处领导掌握。 5. 各配置库的使用人员必须使用各自的用户名和密码进入配置

9、库，访问各自的配置库。各使用人员不得将自己的用户名和密码泄漏给其他人员，若因泄露密码而引起的后果将由泄漏密码者本人承担。6. 项目组成员未经项目经理同意不得更改他人的文档和代码。各项目的配置库用于项目组正式开发使用，项目组成员不得恶意对其进行修改、删除、增加等操作；若因对配置工具不熟悉，需要学习，可以向配置管理员提出需求，由配置管理员为其提供可以练习的配置库。7. 配置管理员负责定期检查配置库的使用情况，查看是否有员工进行无故删除或恶意修改文件的行为;并对开发人员提交的文档和代码的及时性、准确性和完整性进行检查。8. 在研发人员离职时，由其项目经理负责检查配置库，检查该人员提交的代码或文档是否

10、完全放入配置库管理，确认版本和相应文件完整无误后，项目经理在“员工离职申请单”中签字，该员工方可离职。同时项目经理应及时通知配置管理员，取消该人员的所有权限。若因项目经理审核不细致造成的代码或文档移交不完整，或项目经理未及时通知配置管理员取消权限，而造成的损失，该责任完全由项目经理承担。9. 代码提交原则（1）每次提交代码前，先进行更新，以避免提交冲突。（2）代码提交前，应对每个文件与前一版本进行比较，仔细查看差异之处，减少错误以及避免提交临时代码。（3）提交到配置管理中的代码必须能正确编译。常见的问题是创建了新文件，但没有加到配置管理中，导致其它人更新代码后编译不过。（4）代码提交前先使用代

11、码格式化工具和代码规范检查工具处理。（5）原则上应在完成某个功能或函数的开发或修改之后，再提交代码，避免提交功能不完整的代码。（6）如果在修改了涉及多个子任务的多个文件后进行提交，最好按问题的相关性分成几次进行提交，每次只提交单个子任务相关的文件并写上注释。 附录一：配置项命名规则配置项目命名基本要求：唯一性；可追溯性。1项目名称命名规范：要求项目名称不能太长，且必须要求使用该项目的英文缩写命名。项目名称中最好不出现空格，若有空格，在建立配置库时，配置库名中将以“_”来代替空格。2配置库命名配置库分为开发库和基线库。Ø 项目的基线库有多个,可以在其下建立各版本的基线库,子基线库命名规

12、则为:项目名称缩写+版本号_basØ 若一个项目的开发库有多个,可以在其下建立各版本的开发库,子开发库的命名规则为:项目名称缩写+版本号_dev3技术文档命名：技术文档的标识体现在相应文件的封面上，规范如下：文档名称版本, 由开发人员参照相应文档模板的格式要求，对技术文档进行标识。附录二：配置库目录结构管理规定每一个项目的配置库可分为devlib（开发库）、testlib（测试库）、PMlib（ProjectManagementLib 项目管理库）和baselib（基线库或产品库）；基线库与开发库结构相同，但基线库和开发库各自独立，分开管理，其中基线库只有配置管理员有操作权限，其他人员只有读权限。每个项目的都按如下表目录规则规划，其中devlib、testlib、PMlib、baselib、docs、src目录为必选项，其它目录可以根据实际情况增减：一级目录二级目录三级目录四级目录部门代号_项目名称_版本号devlibdocs需求分析概要设计详细设计数据库结构技术规范产品相关资料使用说明书技术说明书鉴定文档其它技术文档src源代码数据库发布包(rele