软件配置管理计划

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

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

​ 作 者： XXX

​ 审 核 人： XXX

​ 审核日期： 2023.6.15

​ 批 准 人： XXX

​ 批准日期： 2023.6.15

​ 文档修订信息

修改人	修改内容	修改原因	版本信息
XXX	初稿完成		V1.0
XXX	新增6.1变更管理流程	为保证软件质量，需保证开发过程中变更管理的规范性	V2.0

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

术语表：

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

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

1、概述

1.1 目的和范围

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

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

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

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

1.3 参考资料

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

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

2. 角色与职责

2.1 项目配置管理工程师

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

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

2.2 项目经理

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

2.3 其他人员

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

工作。

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

角色	职责	责任人
市场代表	搜集市场需求，整理需求说明书，向客户传递软件版本	XXX
项目经理	项目立项与项目进度安排，人力资源安排，关键里程碑点的评审与决策	XXX
架构设计师	需求梳理，架构设计，概要设计	XXX
开发工程师	详细设计，代码编写，集成版本，解决bug	XXX
测试工程师	编写测试方案与策略，计划，用例，报告，执行测试，输出软件产品质量分析报告	XXX
资料工程师	根据软件产品编写安装指南，操作指导书，在线帮助，用户手册等须交付客户的文档	XXX
配置管理工程师	制定相关规范和标准，维护配置管理工具，确保软件开发过程中的版本控制、变更管理、构建管理、发布管理等环节的规范执行。	XXX
质量保证工程师	制定项目质量保证计划，搜集数据与分析，审计，制定质量提升解决方案	XXX

3．配置项识别

3.1文档

文档清单

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

限。

注意，该项目中：

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

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

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

文档名称	基线日期	版本	作者	审核人	存放路径
图书管理系统项目windows批处理脚本	2023.4.1	V1.0	XXX	XXX	gitee或者github仓库地址
图书管理系统需求分析说明书	2023.4.3	V1.0	XXX	XXX	gitee或者github仓库地址
图书管理系统系统设计说明书	2023.4.7	V1.0	XXX	XXX	gitee或者github仓库地址
图书管理系统测试文档	2023.4.20	V1.0	XXX	XXX	gitee或者github仓库地址
图书管理系统项目验收说明书	2023.5.10	V1.0	XXX	XXX	gitee或者github仓库地址
图书管理系统构建指导书，部署指南	2023.5.15	V1.0	XXX	XXX	gitee或者github仓库地址

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

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配置库权限管理（根据实际情况编写）

责任人	文件权限
XXX	读：需求分析，系统设计 写：需求分析，系统设计，测试
XXX	读：测试、系统设计、需求分析、项目验收 写：项目验收、测试、系统设计、需求分析、项目验收
XXX	读：测试、系统设计、需求分析 写：系统设计、windows批处理脚本

4.4 配置库扩容

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

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

5、基线管理

5.1 基线计划

技术评审点	基线名称	基线时间
TR1、TR2、TR3	需求/计划基线	2023.4.1
TR4、TR5	转测试基线	2023.4.10
TR6	发布基线	2023.5.10

5.2基线活动

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

基线时间点前一个星期：

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

2. 检查文档规范；

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

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

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

5.3基线报告

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

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

基线名称	基线时间	标签位置	权限设置情况
需求计划基线	2023.05.17	存放需求计划基线地址	全部只读

2. 报告体现形式

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

3. 基线发布时间

​ 基线后一周内。

6、变更管理

6.1 变更管理流程

6.1.1 配置项修改

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

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

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

缺陷/变更单号：xxx缺陷

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

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

审核人：xxx

6.2.2 变更流程

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

​ 图6-1 缺陷管理流程

6.2变更管理报告

变更报告内容：

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

变更对象：

新增成绩的导入功能

变更原因：

客户提出：在录入成绩过程中，工作量太大，而且容易出错

变更内容：

新增通过EXECE格式导入系统成绩的功能，格式为：学号+姓名+期中成绩+期末成绩+总成绩

评审人员：市场代表，项目经理，架构设计师，开发，测试经理，配置管理工程师，质量经理。

评审日期：2023-05-18

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.

测试计划：

版本发布日期	版本名称	发布者
2023-04-18	缺陷管理系统D001	XXX
2023-04-25	缺陷管理系统D002	XXX
2023-04-30	缺陷管理系统D003	XXX
2023-05-18	缺陷管理系统T001	XXX
2023-05-25	缺陷管理系统T002	XXX
2023-06-5	缺陷管理系统T003	XXX

8.2版本发布计划

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

版本号	发布时间	面向的用户
缺陷管理系统1.0	2023.05.16	XXX
缺陷管理系统2.0	2023.05.21	XXX
缺陷管理系统3.0	2023.06.12	XXX

8.3版本发布流程

1. 发布要求：

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

2. 发布途径：

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

3. 发布版本内容：

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

8.4版本发布报告

发布的版本	计划发布时间	实际发布时间	面向客户	备注
1.0	2023.05.16	2023.05.17	全体用户	无
2.0	2023.05.21	2023.05.22	全体用户	无
3.0	2023.06.12	2023.06.13	全体用户	无

9、配置状态报告发布

报告类型	报告发布周期	面向的项目组人员
基线报告	事件触发（各基线时间点）	全体人员
变更报告	事件触发（有变更时）	设计，开发，测试相关人员
缺陷管理报告	两周一次	主送责任人，抄送全体人员
配置管理报告	每月一次（需包含配置管理计划中全部活动的内容）	全体人员
审计报告	事件触发	主送责任人，抄送全体人员

10、归档数据

10.1归档内容

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

10.2归档活动

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

11 配置审计

11.1审计内容

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

11.2审计报告

发现的问题	问题分类	责任主体	计划完成日期	问题当前状态
代码修改后没有注释	注释	开发人员	2023.05.12	已完成
文档没有修改	文档类型	设计人员	2023.05.30	已完成
文档版本不对	文档类型	设计人员	2023.06.12	已完成