说明：这个学期我在软件配置管理这个课上完成了软件配置管理计划，分享出来，可以参考下面的模板，希望能对园友有一些帮助。

​ 文档名称：图书管理系统项目软件配置管理计划与策略

​ 作 者： XXX

​ 审 核 人： XXX

​ 审核日期： 2023.6.15

​ 批 准 人： XXX

​ 批准日期： 2023.6.15

​ 文档修订信息

关键词：软件，配置管理，基线，变更，配置项，审计，配置库

术语表：

图书管理系统项目软件配置管理计划与策略

1、概述

1.1 目的和范围

本文档描述图书管理系统项目的软件配置管理计划，该计划向图书管理系统项目组以及相关受SCM活动影响的组和个人提供相应的说明和操作指南，使图书管理

系统项目的SCM计划与策略能够在图书管理系统项目的SCM活动中得到落实，达到规范开发过程管理、保证软件产品质量的目的。本计划适用于图书管理系统项目的整个生命周期。

1.2 软件配置管理计划与策略维护

计划由图书管理系统项目的项目经理和项目配置管理工程师共同制订。如果计划中的SCM活动在实施中出现偏离，由项目配置管理工程师及时审计与纠正。

1.3 参考资料

《图书管理系统项目软件开发计划书》，V1.3；

《软件配置管理流程》，V1.1；

2. 角色与职责

2.1 项目配置管理工程师

项目配置管理工程师的职责是制定《图书管理系统项目软件配置管理计划与策略》及有关规程；指导与监督项目组人员进行软件配置管理活动；并对配置管理的开

展情况进行定期或者事件触发性的检查与发布。

2.2 项目经理

须协助项目配置管理工程师在软件项目的研发过程中严格执行《图书管理系统项目软件配置管理计划与策略》中的要求与规范。

2.3 其他人员

图书管理系统软件项目组的需求分析人员，架构设计人员，开发人员，测试人员，资料人员等须按照《图书管理系统项目软件配置管理计划与策略》落实配置管理

工作。

2.4 图书管理系统项目人力资源信息

3．配置项识别

3.1文档

文档清单

该项目需要纳入配置管理的文档类配置项如下表所示，在各个关键阶段点（TR3，TR5,TR6），文档负责人须提交经过评审后的文档到配置库，收回文档的修改权

限。

注意，该项目中：

1. TR1+TR2+TR3合并，输出需求和设计类文档，并基线；

2. TR4+TR5合并，输出开发相关文档，并基线；

3. TR6，输出测试类文档，并基线。

注意：关键阶段点代表的意思如下：

TR1（Technology Readiness Level 1）：

概念论证阶段，主要是确定产品的基本概念和技术可行性。

TR2（Technology Readiness Level 2）：

需求分析阶段，主要是对产品的功能、性能、质量、安全等需求进行详细分析和规划。

TR3（Technology Readiness Level 3）：

设计阶段，主要是依据需求分析结果，进行产品的整体设计和具体模块设计。

TR4（Technology Readiness Level 4）：

开发阶段，主要是进行软件和硬件的开发，包括编码、测试、验证等。

TR5（Technology Readiness Level 5）：

验证阶段，主要是对产品进行全面的验证和测试，确保产品符合需求和质量标准。

TR6（Technology Readiness Level 6）：

生产阶段，主要是进行产品的制造和交付。

总之，华为研发六阶段概念覆盖了产品研发的各个方面，从产品概念到生产交付全程都有详细的规划和流程。

文档命名

项目名称+文档内容+版本号

如：图书管理系统需求说明书V1.0

版本号说明：如果是针对文档进行大的改动，比如：新增了几个重要的需求，那么从“.”号前面升级，即，版本升级为V2.0，如果只是修改几个错别字，或者规范问

题，则从“.”号后面升级，即，版本升级为V1.1。

文档密级

1. 绝密:一旦泄密会使公司利益遭受特别严重的损害；

2. 机密:一旦泄密会使公司利益遭受严重的损害；

3. 秘密:一旦泄密会使公司利益遭受较大的损害；

4. 内部公开:一旦泄密会使公司利益遭受一般损害；

5. 公开资料：公开有助于公司利益。

​ 各文档作者可根据文档内容的重要性制定文档密级。

3.2代码

项目开发过程中，所产生大量的源代码，都必须存放到配置库的指定目录下；假设一个开发组有5个开发人员在写代码，他们该如何获取代码，修改好后，如何合

入到版本库中呢？举例：每天早上上班开始，首先从版本库中下载最新的代码，然后每个人在各自的电脑上修改代码，修改好后（确认编译通过，自测试没有发现

问题），再将自己的代码合入到版本库中。此外，为了保证代整体质量，需要使用持续集成环境对代码进行编译构建和测试，建议每晚进行构建，开发人员第二天

上班先查看构建日志，有问题，立刻修改。

代码开发后，须存放到配置库的指定目录下，各团队自行决定存放路径。

代码在转测试（TR5）和正式对外发布（TR6）时需要打个标签，记录在这两个关键点上代码的状态。后续每发布一个版本或补丁，也需要打个标签。做到这一

点，可以方便版本的追溯，举个例子：有很多个版本，各个版本之间如何识别，有哪些差异，都需要标识出来，过后回过头来查找，就好像我们自己在家里的分类

抽屉里找东西，得心应手。

源代码、开发环境、编译脚本等生成系统的必须的配置项都要纳入配置管理。

4、配置库管理

4.1配置管理工具

考虑到稳定性，易用性，购买和维护成本，项目选择的是Git，项目团队中的每个人员在访问仓库地址之前，都需要首先在自己工作电脑上安装一个Git工具，方便

进行代码的拉取和推送。

4.2配置库目录结构

目录结构规划如下，请全体人员按照目录结构分类存放文档与代码。

版本库路径：gitee或者github的仓库地址

4.3配置库权限管理（根据实际情况编写）

4.4 配置库扩容

产品级配置管理工程师定期统计配置库的容量，若剩余容量小于警戒值（20G），则产品级配置管理工程师知会项目级配置管理工程师，项目级配置管理工程师与

所在项目的项目经理确认后，发起扩容申请。通过后扩容配置库。

5、基线管理

5.1 基线计划

5.2基线活动

项目配置管理工程师所做的工作：

基线时间点前一个星期：

1. 检查文档的交付情况；

2. 检查文档规范；

3. 检查文档与代码的变更情况是否符合规范；

4. 检查缺陷是否符合质量要求，TR5时缺陷个数不能超过12个，且不能有严重和致命的缺陷；TR6时缺陷个数不能超过6个，且不能有严重和致命的缺陷。

基线时间到时，项目配置管理工程师为代码和文档打标签，收回文档的修改权限。并发布基线报告给相关人员。

5.3基线报告

1. 基线报告，至少需要包含如下内容：

​ 基线名称，基线时间，标签位置，权限设置情况。

2. 报告体现形式

​ 以EXCEL形式体现，并通过邮件形式发布给相关人员。

3. 基线发布时间

​ 基线后一周内。

6、变更管理

6.1 变更管理流程

6.1.1 配置项修改

全部配置项（文档、代码和其他工作成果），需要按照如下流程来完成。

对于代码，修改时，需要添加注释。

对于代码和文档，在修改后提交到版本库前，需要填写如下模板来填写：

缺陷/变更单号：xxx缺陷

修改原因：因为发现xxbug,所以进行修复

修改内容：改了xx文档，xx文件中第几行到第几行代码

审核人：xxx

6.2.2 变更流程

对于缺陷，发现缺陷后，需要按照如下流程处理：（根据自身项目特点设置缺陷处理流程）

​ 图6-1 缺陷管理流程

6.2变更管理报告

变更报告内容：

变更对象，变更原因，变更内容，评审人员，评审日期。

7、缺陷管理

7.1 缺陷管理规范

管理流程按照图6-1执行。

管理规范：凡是发现的问题，都必须走缺陷管理流程，各个节点须体现的内容：

提交问题

问题发现人：XXX

环境配置：win10操作系统

发现问题的版本：1.02

操作步骤：先修改设计文档，再修改代码。

预期结果：功能恢复到预期结果

实际结果：功能达到预期

问题严重程度：一般

缺陷所属模块：按钮失去点击效果

审核问题（测试经理）：

问题描述是否规范？是

是否确实是问题？是

是否重复问题？否

指定问题定位人：XXX

开发人员定位并修改问题

问题现象：按钮失去点击功能

问题根因：前端没有添加点击触发事件

计划的解决方案：修改前端代码。

修改了哪些文件？book.html

验证结果如何？达到预期

解决问题的版本？1.02

配置管理工程师归档

测试经理审核

验证问题是否解决的版本：是

指定验证人：XXX

测试人员验证问题

验证版本：1.02

操作步骤：先查看设计文档，再查看前端代码

验证结果：达到预期

关闭问题单

问题解决关闭

此问题解决，但引入新的问题，需重新提交一个缺陷跟踪单（问题单）。

7.2 缺陷管理报告

内容包括：缺陷单号，责任人，严重程度，发现问题的版本，解决问题的版本，验证人。

8、版本发布管理

8.1版本命名规则

1、TR5之前的版本命名：软件名称（建议使用英文全称）+D001（D002，D003，阿拉伯数字一次递增，当增到D009时，采用D010，D011.，依次类推）；

2、TR5后，TR6前的版本命名：软件名称（建议使用英文全称）+T001（T002，T003，阿拉伯数字一次递增，当增到T009时，采用T010，T011.，依次类推）；

3、TR6后发布版本的命名规则：软件名称（建议使用英文全称）+1.0（2.0,3.0，一次递增）；如果是补丁版本，例如：基于2.0发的第一个补丁版本（解决了某个问题），那么补丁版本号是：软件名称（建议使用英文全称）+2.1；

发布第二个补丁的版本号：软件名称（建议使用英文全称）+2.2.

测试计划：

8.2版本发布计划

根据项目组实际情况制定版本发布计划：

8.3版本发布流程

1. 发布要求：

​ 所有发布的版本，必须是经过测试，且符合版本发布要求的版本（如5.2节中的第4项）；

2. 发布途径：

​ 由项目配置管理工程师将版本放置在某个发布版本的固定目录下，然后由版本获取人获取并发布给客户。

3. 发布版本内容：

​ 安装包，安装指导，使用指南，在线帮助，系统测试报告（可根据项目实际情况进行裁剪）。

8.4版本发布报告

9、配置状态报告发布

10、归档数据

10.1归档内容

软件项目开发过程中所产生的全部有用的工作成果，也就是在项目初期识别出来的配置项。

10.2归档活动

将数据从项目级配置库归档到公司或企业的产品级配置库中，归档后全部数据只保留读权限。

11 配置审计

11.1审计内容

项目组的配置管理活动是否按照《配置管理计划与策略》中的要求与规范落实，监控与督促过程规范，保证产品质量。

11.2审计报告

本栏目推荐文章
• 多项式定积分计算软件2025 64位WIN版下载Polynomial definite integral calculation software 2025 64 bit WIN version download
• Mac上运行windows软件-GPTK
• 软件构造大作业 综合信息管理系统
• 成绩管理系统软件体系结构设计说明书
• 【GUI软件】抖音搜索结果批量采集，支持多个关键词、排序方式、发布时间筛选等！
• 软件架构实践 V2：第二章
• 软件测试
• Parallels Desktop 19：强大与便捷并存的虚拟机软件
• 软件测试报告模板
• 软件测试/测试开发全日制|Pytest中yield的用法详解

软件eplan软件 软件库 mimics软件 软件测试 软件cae 分析软件 软件开发 linux软件 开发软件 ubuntu软件