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

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

​ 作 者： XXX

​ 审 核 人： XXX

​ 审核日期： 2023.6.15

​ 批 准 人： XXX

​ 批准日期： 2023.6.15

​ 文档修订信息

Software Configuration Management Plan（软件配置管理计划） 在软件项目的整个生命周期过程中，为如何开展与落实配置管理工作制定的详细，可落实的规划 Configuration Item（配置项） 所有软件生命周期过程中产生的需纳入配置管理的工作成果，如：代码，文档，工具等 Software Configuration Management（软件配置管理） 是一套应用技术上和管理上的指导和监督的方法，用来识别和记录 配置项 的功能特征和物理特征；控制这些特征的 变更 ；记录和报告变更的处理和执行的状态；以及验证其是否符合特定的需求 Configuration Management Engineer（配置管理工程师） 在软件项目开发过程中开展配置管理工作的人员，主要负责制定配置管理计划与策略，针对项目进行配置库的建立和维护，负责基线管理，变更管理，版本发布，配置管理状态报告的发布，执行配置审计等相关工作。 Change Request（变更请求） 变更请求（CR）用于记录和追踪缺陷、相关请求和任何其他类型的系统变更请求。

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

1.1 目的和范围

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

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

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

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

1.3 参考资料

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

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

2. 角色与职责

2.1 项目配置管理工程师

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

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

2.2 项目经理

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

2.3 其他人员

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

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

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。

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

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

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

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

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

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

3.2代码

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

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

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

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

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

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

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

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

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

4、配置库管理

4.1配置管理工具

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

进行代码的拉取和推送。

4.2配置库目录结构

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

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

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

4.4 配置库扩容

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

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

5、基线管理

5.1 基线计划

技术评审点

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

​ 图6-1 缺陷管理流程

6.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.

测试计划：

版本发布日期

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

10.2归档活动

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

11 配置审计

11.1审计内容

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

11.2审计报告

发现的问题 计划完成日期 问题当前状态