软件配置管理制度

软件配置管理制度篇一：配置管理制度软件配置管理制度 (讨论稿) 1 概述 目的 为了保证研发项目文件的安全性、机密性；保证软件产品的完整性、有效性及可追溯性，以及加强研发项目的协同能力，特制订本制度。 范围 适用于公司所有研发项目。 术语 角色与职责 2 配置管理范围 研发项目过程中产生的所有文档，包括：研发项目管理文档、研发设计及技术文档、源代码、可执行程序，工具及相关资料等。 ? 项目文档主要：立项书、项目计划、例会会议记录及项目过程中管理类文档等。 ? 设计及技术文档主要：需求，需求分析报告、概要设计说明书、详细设计说明书、数据库表结构、 测试文档、使用说明书、技术说明书等。 ? 工具及其相关资料：开发或测试过程中的工具，以及其使用文档等，如觉得有必要也纳入配置库的 管理。 3 项目配置库建立与使用 项目配置库建立 1. 项目立项时，由项目经理申请建立项目配置库（附录二 X配置库申请单 ） 2. 配置管理员与项目经理根据配置管理的流程确定配置管理计划 。 3. 配置项：项目经理与配置管理员共同确认研发项目的配置库目录结构，并建立配置库目录结构；所建配 置库目录结构必需按本文规定目录结构执行（目录结构参考附录二） 。 4. 项目小组：项目经理提供项目小组成员名单及联系方式，配置库权限清单（内容应包括员工姓名、目录 权限等） 5. 权限分配：配置管理员为相关人员的设置配置权限。配置库权限设置完成之后，由配置管理员将配置库 名称、访问路径、访问权限等信息以邮件方式通知各相关人员；配置库使用人员以各自的用户名和密码进行访问配置库。 6. 配置库密码只能在服务器上设置，如配置库使用人员密码遗忘或需要修改，可以与配置管理员取得联系， 进行修改密码。 项目配置库使用 1. 配置库目录说明 配置库基本结构如“”所示，以项目名称作为一级目录，二级目录包括：devlib、testlib、PMlib、 baselib：“devlib”：项目小组日常研发活动区；该目录包含docs（设计文档） 、src（代码）目录。 “PMlib”：放项目管理文档，为科研处项目管理部门和项目经理使用； “testlib”：项目小组在此目录下记录项目测试中的文档，如内部测试、中试申请、中试报告、评 审纪要。 “baselib”：仅放置 PLM 发布版本，项目经理具有读权限；开发人员在该目录下不允许对源代码 等文件进行修改。 2. 配置库使用说明 a) 项目开发小级在“devlib”进行日常开发活动。 b) 项目经理在“PMlib”中记录项目管理文档。 c) 项目进行到中试测试阶段，由项目经理通过“branch/tag”（中文为：“分支/标记” ）的方式， 将“devlib”在“testlib/测试版本”中建立版本分支。再由项目管理员从此库中“导出” ， 并根据 PLM 入库相关的规定，通过 PLM 相关流程进行中试测试。中试测试过程中产生的 文档记录在“testlib”相关目录中。 d) 中试测试合格，科研处在进行对项目发布前，将“testlib/测试版本”中建立的版本分支在 “baselib”建立发布版本分支。 4 权限变更 使用配置库的过程中需要变更配置库管理权限，由项目经理填写配置库权限变更单 ，并以邮件方式通知配置管理员，配置管理员变更之后，将变更结果以电子邮件方式通知受影响的人员、项目经理及其相关人员。 配置管理员根据配置库权限变更频率，每隔一段时间将配置库权限清单与各项目经理进行审核确认。 5 配置库安全 ? 配置服务器系统安全：配置管理员进行服务器的日常管理与维护，做好防入侵、防病毒工作。 ? 配置库备份：配置管理员定期做好配置库的备份，以防意外，避免给公司带来严重的损失。 配置管理员每日进行硬盘备份一次，每周进行异地硬盘备份一次，每月进行光盘备份一次,备份后的光盘 标记上备份日期并附上内容清单，移交公司相关部门保管。6 配置库使用规范 1. 各项目必需使用科研处提供的配置管理环境建立配置管理库。 2. 配置管理员由科研处任命，科研处负责进行配置管理的管理工作。 3. 所有立项的科研项目，都必须申请建立配置库。开发过程中所有文档和代码必须纳入配置库管理。 4. 配置库服务器密码只有配置管理员及科研处领导掌握。 5. 各配置库的使用人员必须使用各自的用户名和密码进入配置库，访问各自的配置库。各使用人员不得 将自己的用户名和密码泄漏给其他人员，若因泄露密码而引起的后果将由泄漏密码者本人承担。 6. 项目组成员未经项目经理同意不得更改他人的文档和代码。各项目的配置库用于项目组正式开发使用， 项目组成员不得恶意对其进行修改、删除、增加等操作；若因对配置工具不熟悉，需要学习，可以向配置管理员提出需求，由配置管理员为其提供可以练习的配置库。 7. 配置管理员负责定期检查配置库的使用情况，查看是否有员工进行无故删除或恶意修改文件的行为;并 对开发人员提交的文档和代码的及时性、准确性和完整性进行检查。 8. 在研发人员离职时，由其项目经理负责检查配置库，检查该人员提交的代码或文档是否完全放入配置 库管理，确认版本和相应文件完整无误后，项目经理在“员工离职申请单”中签字，该员工方可离职。同时项目经理应及时通知配置管理员，取消该人员的所有权限。若因项目经理审核不细致造成的代码或文档移交不完整，或项目经理未及时通知配置管理员取消权限，而造成的损失，该责任完全由项目经理承担。 9. 代码提交原则 （1）每次提交代码前，先进行更新，以避免提交冲突。 （2）代码提交前，应对每个文件与前一版本进行比较，仔细查看差异之处，减少错误以及避免提交临时代码。（3）提交到配置管理中的代码必须能正确编译。常见的问题是创建了新文件，但没有加到配置管理中，导致其它人更新代码后编译不过。 （4）代码提交前先使用代码格式化工具和代码规范检查工具处理。 （5）原则上应在完成某个功能或函数的开发或修改之后，再提交代码，避免提交功能不完整的代码。 （6）如果在修改了涉及多个子任务的多个文件后进行提交，最好按问题的相关性分成几次进行提交，每次只提交单个子任务相关的文件并写上注释。 篇二：软件配置管理规定ST/GD/731 软件配置管理规定 拟制 审核 批准 版本 XX 年 01 月发布 XX 年 01 月实施 ST/GD/731 修 改 履 历 ST/GD/7311 目的 编制本规定的目的是为了规范公司软件研制的软件配置管理工作，确保应用软件的正确性、适宜性、完整性和可跟踪性。 2 范围 本规定适用于公司所有涉及软件研制项目的软件配置管理和控制。 本规定起始于软件开发库的建立。 本规定结束于软件进入产品库以及相关记录归档。 3 术语和定义 软件配置：指一个软件产品在软件生存周期各个阶段所产生的各种形式（机器可读或人工可读）和各种版本的文档、程序及其数据的集合。 软件配置管理：软件配置管理是对软件修改进行标识、组织和控制的技术，用来协调和控制整个过程。是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保开发人员在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 配置项：凡是纳入配置管理范畴的工作成果统称为配置项。配置项逻辑上是组成软件系统的各组成部分，一般是可以单独进行设计、实施和测试的。配置项分为一般配置项和受控配置项。配置项及其历史记录反映了软件的演化过程。 开发库：指在软件生存周期的某一个阶段期间，存放与该阶段软件开发工作有关的计算机可读信息和人工可读信息的库。由开发人员控制变更。 受控库：指在软件生存周期的某一个阶段结束时，存放作为阶段产品而释放的、与软件开发工作有关的计算机可读信息和人工可读信息的库。由项目负责人控制变更。 产品库：指在软件生存周期的组装与系统测试阶段结束后，存放最终产品而后交付给用户运行或在现场安装的软件的库。由项目负责人控制变更，顾客可以参与。 4 职责 产品系统部 软件工程师负责开发库的建立和管理。 项目负责人负责组织软件进入受控库和产品库前的评审及入库软件的提交。 软件配置管理由研发生产部负责组织实施。 综合部 综合部文件管理员负责受控库和产品库的建立和管理。5 过程描述 配置项 配置项的范围 配置项一般包括以下内容：A. 文档类：软件研制分任务书 、 软件概要设计书 、 软件模块测 试方法 、 软件模块测试报告 、 软件系统测试方法、 软件系统测试报告 、 会议记录 、 信息反馈记录 、软件版本信息记录等。 B. 软件类：程序源代码、可执行程序、软件安装包、系统镜像文件等。 C. 工具类：开发工具、测试工具、维护工具等。 D. 其它：板卡固件源码、板卡通信协议、板卡驱动程序源码、板卡驱动程 序使用说明书、系统驱动程序、外来程序及说明等。 配置项的内容可以根据项目实际情况进行增减。 配置项标识方式 配置项标识必须包括：名称、编号、版本、实施人、日期等，可根据需要增加其他标识。 软件名称 软件名称格式为“XXXXXX” ，其中“XXXXXX”为按照项目确定的代号。如“H2/SCH-1 视频采集回放测试仪” ，软件名称为“H2SCH1” 。 文档名称 对于配置项中的所有文档其命名按公司ST/GD/42301 技术文件管理规定执行。 软件版本 软件版本用三位符号表示：“” 。 “X”为主版本号，“Y”为第二版本号，表示增加功能时的版本升级， “Z”为第三版本号，表示纠正错误时的版本升级，各版本号均用一位数字表示。对产品作重大调整，或与已发行的上一产品相比，在功能与性能上有较大区别时主版本号增加。与上一产品或项目相比，功能进行了小量的增加或修正时，第二版本号增加。对上一次产品或项目中的缺陷做修正，第三版本号增加，第三版本号为零时可以省略不写。 开发库建立时软件版本号为“” ，首次进入产品库时软件版本号为“” 。 文档版本 对于配置项中的所有文档其版本分配按公司ST/GD/42301 技术文件管理规定执行。 开发库的建立和管理 软件工程师根据软件研制分任务书 ，填写软件配置项清单 ，在个人计算机上建立项目软件开发库。 软件工程师根据软件配置项清单建立配置项，并进行标识。 软件工程师根据项目开发进度随时建立新的配置项，并添加在软件配置项清单中。软件工程师可以控制开发库中配置项的更改。更改文档类配置项，按照ST/GD/42301 技术文件管理规定执行。更改软件类配置项时，应同时更新软件版本信息记录。更改前，记录更改开始时间、更改人、更改原因和期望结果；更改后，记录更改完成时间、更改内容、实际效果、遗留问题和更改涉及到的配置项。 受控库和产品库的建立和管理 入库的准备 项目负责人在项目开发计划中规定的时间节点前组织入库软件的评审，并填写评审报告 。 项目负责人填写软件入库申请单 ，连同入库软件评审报告和软件配置项清单交由总工程师审批。项目负责人将审批后的软件入库申请单 、 软件配置项清单提交至文件管理员处。文件管理员实施入库操作。 受控库和产品库的建立 配置项首次入库，项目负责人应提交软件配置项清单中的全部内容。除首次入库外，只提交更改涉及的配置项。 配置项的更改 更改申请 发起者（顾客、项目负责人或软件工程师）确定更改后，项目负责人填写设计开发更改单 。在设计开发更改单中描述更改原因、期望结果和实施人员；项目负责人组织相关人员对设计开发更改单进行评审，并填写评审报告 。评审要分析每项更改对系统功能、接口、成本、进度以及约定需求的影响，以及更改对软件安全性、可靠性、可维护性、可移植性和性能的影响。 项目负责人将设计开发更改单连同评审报告交由总工程师审批。 如设计开发更改单未通过评审或审批，项目负责人将设计开发更改单连同评审报告提交给文件管理员存档。 更改实施 项目负责人将审批通过的设计开发更改单连同评审报告提交给文件管理员。文件管理员根据中描述的内容，在受控库或产品库中复制出各配置项的最终版本，连同更改涉及的资源和设计开发更改单分发给实施人，开始实施更改。同时，文件管理员在软件配置项清单中，将更改的配置项“备注”中注明“ 修改中、设计开发更改单号。 更改实施人负责实施更改，并在软件版本信息记录中详细记录更改内容。项目负责人对更改的实施进行跟踪。对于软件类配置项的更改，必须对软件规格说明书 、软件概要设计说明书 、 软件模块设计说明 、 软件模块测试方法 、 软件模块测试报告 、 系统软件测试方法 、系统软件测试报告等文件中的相关内容进行修改，并重新进行测试。当项目开发计划发生更改时，软件工程师应按照更改的项目开发计划提交配置项。 更改确认 更改完成并通过测试后，实施人应将设计开发更改单连同更改后的配置项，提交给项目负责人，由项目负责人组织评审，并填写评审报告 。 更改内容如未通过评审，项目负责人应将设计开发更改单返还给实施人，由实施人重新实施更改。 更改内容如通过评审，项目负责人应将设计开发更改单连同更改后的配置项和评审报告 ，提交给技术文件管理员。技术文件管理员实施入库操作，在软件配置项清单中做相应更新。 受控库和产品库的管理 配置项的保存 受控库和产品库均由文件管理员负责保存。电子版配置项保存在技术文件管理员使用的计算机上和备份存储器上，纸质版配置项保存在专用文件柜中。文档类配置项均需以纸质版和电子版保存，软件类配置项只保存电子版。 配置项的备份 文件管理员应在每年 1 月、7 月及项目完成后备份受控库和产品库中各配 篇三：软件配置管理规范流程1 概述 目的 本文档主要目的在于规范项目配置管理活动，确保配置项正确地唯一标识并且易于存取，保证基线配置项的更改受控，明确基线状态，在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 适用范围 本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动，针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法，本文件以 CVS（并行版本系统）配置管理工具为例，规定公司的配置管理办法，使用其他工具时也可对应本文件的要求参照执行。 术语和缩略语 软件配置管理（Software Configuration Management，SCM） 软件配置管理是对软件修改进行标识、组织和控制的技术，用来协调和控制整个过程。是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 配置项（Configuration Item，CI） 凡是纳入配置管理范畴的工作成果统称为配置项，配置项逻辑上组成软件系统的各组成部分，一般是可以单独进行设计、实施和测试的。 每个配置项的主要属性有：名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 基线（Baseline） 在配置管理系统中，基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，这些配置项构成了一个相对稳定的逻辑实体，而这个过程被称为“基线化” 。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素（配置项）的一个版本，且只确定一个版本。一般情况下，基线一般在指定的里程碑处创建，并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制，基线中的配置项被“冻结”了，不能再被 任何人随意修改，对其修改要严格地按照变更控制的过程进行。在一个软件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一个基线。基线的主要属性有：名称、标签、版本、日期等。 权限与职责 研发总经理助理 1） 审核变更请求。 项目经理（Project Manager，PM） 1) 审核批准配置管理计划； 2) 接收或拒绝小范围的变更申请； 3) 召集评估变更； 4) 提出配置管理的建议和要求； 5) 配合配置管理员的工作。 配置管理员（Configuration Management Officer，CMO） 1) 编写配置管理计划； 2) 执行版本控制和变更控制方案； 3) 制定访问控制策略； 4) 负责项目的配置管理工作，包括搭建环境、权限分配、配置库的建立、配置项的控制等； 5) 配置管理工具的日常管理与维护； 6) 配置库的日常操作和维护； 7) 负责配置审核并提交报告； 8) 根据配置部署表单编译发布版本，并维护版本； 9) 对开发人员进行相关的培训； 10) 对配置审核中发现的不符合项，拟订纠正措施，要求相关责任人进行纠正。 11) 监督项目组成员规范的执行情况。 开发人员（Developer） 1) 根据确定的配置管理计划和相关规定，提交配置项和基线； 2) 负责项目组内部测试； 3) 负责软件集成和版本生成；4) 按照软件配置管理工具的使用模型来完成开发任务。 2 实施细则 配置项管理 配置项的范围 软件配置可包括以下几方面：开发文档，代码，第三方控件、插件，参考资料，测试文档，用户文档，项目管理文档，验收文档等。 l 项目文档主要指：立项建议书、可行性分析报告、技术建议书、用户需求说明书、项目计划、项目进度计划、项目阶段性计划、产品需求规格说明书、概要设计报告、详细设计、数据库设计、界面设计、用户操作手册、用户安装手册、培训文档、验收报告以及上述文档的评审记录。l 代码主要指：源代码等。 l 工具主要指：脚本文件、插件、第三方控件等。 配置项基线管理 结合 SPP 和 ISO9000 的相关规定，配置管理员根据配置管理规范及配置管理计划，对配置项进行分阶段管理，每一阶段正式评审通过后纳入受控库，作为该项目的一个基线。 l 项目启动：配置项包括技术建议书、可行性分析报告、用户需求说明书等立项阶段产生的文档，评审或审批通过后建立发布基线。 l 需求阶段：系统调研后开发人员进行需求分析，并整理产品需求规格说明书。产品需求规格说明书经过客户的确认后，建立需求基线。如需升级版本则必须通过评审或审批并得到客户的确认。 l 项目计划：需求分析完成后即可制定项目的开发计划，包括项目计划和主要下属计划。包括项目进度计划、配置管理计划、质量保证计划、测试计划、项目阶段性计划。项目开发计划评审通过后，建立项目计划基线。 l 设计：系统设计可分为概要设计、详细设计、数据库设计、数据库字典、界面设计。针对用户需求规格说明书进行系统设计，配置时应说明系统设计的版本与需求分析报告版本的对应关系。设计说明书评审或审批通过后，建立设计基线。 l 编码（设计实现）：编码按功能模块分子项目，即每个模块记作一个配置项。代码在提交项目组系统测试时建立 Beta 版本，系统测试产品正式发布后建立 Version 版本。l 测试：单元测试和系统测试。单元测试通过提交单元测试报告 ，项目启动后应提交系统测试计划 ，系统测试完成后应提交系统测试报告 。配置时应说明测试的版本与编码版本的对应关系。系统测试完成后建立测试基线。 l 版本发布：项目组提交部署表单 ，CMO 根据部署表单进行编译，发布测试服务器上，并对版本进行维护。同时将发布的版本上传到文档服务器上备份。 l 交付与验收：在交付前配置审核完成后建立产品基线，产品基线包含程序以及有关文档配置项，包括交付文档、代码、工具等。 l 产品部署：部署时应包括操作手册、安装维护手册、维护文档以及必要的业务和技术培训文档。 l 相关资料：相关资料也应作为配置项纳入配置管理，此部分包括： 1) 相关法律、法规；必须遵照或项目组约定的技术规范； 2) 与客户或项目组内部重要的交互信息记录，如会议记录、会谈记录、e-mail 和 MSN 记录等