2024年4月18日发(作者：)
软件配置管理计划书
2.2职责。1
2.3流程。1
2.4工具和技术。2
3配置标识。2
3.1命名约定。2
3.2版本标识符号。2
3.3基线标识符号。2
4配置管理。3
4.1配置项。3
4.2变更控制。3
4.3版本控制。4
4.4审查和审核。4
5配置审计。4
6配置问题解决。5
7培训。5
8质量保证。5
9风险管理。6
10附录。6
引言
本文档旨在规范软件配置管理计划的编写，以确保项目的
顺利进行。本文档包括了定义和缩写词、参考资料、管理、配
置标识、配置管理、配置审计、配置问题解决、培训、质量保
证和风险管理等内容。
管理
在软件配置管理中，机构和职责的分配十分重要。本章节
将介绍机构、职责、流程、工具和技术等方面的内容，以确保
软件配置管理的有效性。
配置标识
配置标识是软件配置管理中非常重要的一部分。本章节将
介绍命名约定、版本标识符号、基线标识符号等内容，以确保
配置标识的准确性和一致性。
配置管理
配置管理是软件配置管理计划的核心内容。本章节将介绍
配置项、变更控制、版本控制、审查和审核等内容，以确保软
件配置管理的有效性。
配置审计
配置审计是软件配置管理计划中必不可少的一部分。本章
节将介绍配置审计的相关内容，以确保软件配置管理的有效性。
配置问题解决
在软件配置管理中，配置问题解决是非常重要的一部分。
本章节将介绍配置问题解决的相关内容，以确保软件配置管理
的有效性。
培训
培训是软件配置管理计划中必不可少的一部分。本章节将
介绍培训的相关内容，以确保软件配置管理的有效性。
质量保证
质量保证是软件配置管理计划中非常重要的一部分。本章
节将介绍质量保证的相关内容，以确保软件配置管理的有效性。
风险管理
风险管理是软件配置管理计划中必不可少的一部分。本章
节将介绍风险管理的相关内容，以确保软件配置管理的有效性。
工具、技术和方法
在软件配置管理过程中，有许多工具、技术和方法可以帮
助组织和管理软件的版本控制、变更控制和问题跟踪。其中包
括版本控制工具、变更管理工具、问题跟踪工具、构建工具、
持续集成工具等。这些工具可以提高软件开发的效率和质量，
同时也可以减少错误和风险。
对供货单位的控制
在软件配置管理中，供货单位是指向组织提供软件或软件
组件的外部实体。为确保软件的质量和可靠性，需要对供货单
位进行控制。这包括对供货单位的选择、评估和监控。在选择
供货单位时，需要考虑其技术能力、质量管理体系、交付能力
等因素。在评估供货单位时，需要进行供货质量的检查和测试。
在监控供货单位时，需要建立供货质量评估体系，及时发现和
解决质量问题。
记录的收集、维护和保存
在软件配置管理中，记录的收集、维护和保存是非常重要
的。这包括软件配置项（SCI）的记录、变更历史记录、问题
报告记录等。这些记录可以帮助组织进行软件版本控制、变更
控制和问题跟踪。同时，这些记录也可以作为软件质量保证的
证据，用于审核和审计。
附录：配置管理报表及其格式
配置管理报表是软件配置管理中的重要文档，用于记录软
件配置项、变更历史和问题跟踪等信息。下面介绍两种常用的
配置管理报表及其格式。
软件问题报告单（SPR）
软件问题报告单（SPR）用于记录软件中存在的问题和缺
陷。其格式包括以下几个部分：
编号：用于唯一标识该问题报告单。
2.问题描述：描述该问题的详细情况。
3.问题分类：将问题归类为软件缺陷、需求变更、设计缺
陷等。
4.问题优先级：根据问题的重要性和紧急程度，确定问题
的优先级。
5.问题状态：记录该问题的处理状态，包括已解决、待解
决、已关闭等。
6.问题解决方案：记录该问题的解决方案和处理过程。
配置管理人员填写内容
配置管理人员需要填写以下内容：
编号：根据规定的编号规则为该问题报告单分配一
个唯一的编号。
2.问题分类：根据问题的性质和类型，将其归类为相应的
问题分类。
3.问题优先级：根据问题的重要性和紧急程度，确定问题
的优先级。
4.问题状态：记录该问题的处理状态，包括已解决、待解
决、已关闭等。
配置管理状态
配置管理状态用于记录软件配置项（SCI）的状态变化。
其格式包括以下几个部分：
名称：记录该配置项的名称。
版本号：记录该配置项的版本号。
3.变更日期：记录该配置项的变更日期。
4.变更描述：描述该配置项的变更内容。
5.变更类型：将变更归类为修复缺陷、新增功能、修改设
计等。
6.变更状态：记录该变更的处理状态，包括已提交、已审
核、已实施等。
配置管理申请人员填写的内容
配置管理申请人员需要填写以下内容：
名称：记录该配置项的名称。
版本号：记录该配置项的版本号。
3.变更描述：描述该配置项的变更内容。
4.变更类型：将变更归类为修复缺陷、新增功能、修改设
计等。
5.变更原因：说明进行该变更的原因和必要性。
6.变更影响：说明该变更对其他配置项和系统的影响。
1.接口规格说明和文档控制的方法需求包括标识和文档控
制，记录和报告接口规格说明和文档控制状态，以及控制软件
和支持其运行的硬件之间的接口。对已交付的接口规格说明和
文档进行修改时需要规定修改的方法。
2.5 实现软件配置管理计划的主要里程碑包括建立配置控
制组、确定各个配置基线、建立接口控制协议、制定评审与检
查软件配置管理计划和规程，以及制定相关的软件开发、测试
和支持工具的配置管理计划和规程。
2.6 适用的标准、条例和约定必须指明所适用的软件配置
管理标准、条例和约定，并说明这些标准、条例和约定要实现
的程度。还需要描述要在本项目中编写和实现的软件配置管理
标准、条例和约定，包括软件位置的标识方法、程序和模块的
命名约定、版本级别的命名约定、软件产品的标识方法、文档
标识方法、文档交付过程、软件产品库中软件产品入库移交或
交付的过程、问题报告、修改请求和修改次序的处理过程、配
置控制组的结构和作用、软件产品交付给用户的验收规程、软
件库的操作，以及软件配置管理活动的检查等。
3.软件配置管理活动需求包括配置标识、配置控制、配置
状态记录与报告以及配置检查与评审等四方面。在配置标识方
面，需要详细说明软件项目的基线，并把它们与软件生命周期
的特定阶段相联系。主要有三种基线，它们是功能基线、指派
基线和产品基线。对于每个基线，需要描述每个基线的项、与
每个基线有关的评审与批准事项以及验收标准，以及在建立基
线的过程中用户和开发者的参与情况。
在产品基线中，需要定义以下元素：产品名称和规则、产
品标识编号、每个新版本的版本交付号、新修改的描述、修改
交付的方法、对支持软件的修改要求以及对有关文档的修改要
求、安装说明、已知的缺陷和故障、软件媒体和媒体标识。
在本条中，必须描述本项目所有软件代码和文档的标题、
代号、编号以及分类规程。例如，对代码来说，编译日期可以
作为每个交付模块标识的一部分。同时，在构造模块源代码的
顺序行号时，应使它适合于对模块作进一步的修改。
必须描述在本计划第2.2条描述的软件生存周期中各个阶
段使用的修改批准权限的级别。同时，必须定义对已有配置的
修改建议进行处理的方法，其中包括详细说明在本计划第2.2
条描述的软件生存周期各个阶段中提出修改建议的程序（可以
用注上自然语言的流程图来表达）、描述实现已批准的修改建
议（包括源代码、目标代码和文档的修改）的方法、描述软件
库控制的规程，其中包括存取控制、对于适用基线的读写保护、
成员保护、成员标识、档案维护、修改历史以及故障恢复等七
项规程。如果有必要修补目标代码，则要描述其标识和控制的
方法。
对于各个不同层次的配置控制组和其他修改管理机构，本
条必须定义其作用，并规定其权限和职责。如果已组成机构，
则指明该机构的领导人及其成员。如果还没有组成机构，则说
明怎样任命该机构的领导人、成员及代理人。同时，说明开发
者和用户与配置控制组的关系。当要与不属于本软件配置管理
计划适用范围的程序和项目进行接口时，本条必须说明对其进
行配置控制的方法。如果这些软件的修改需要其他机构在配置
控制组评审之前或之后进行评审，则本条必须描述这些机构的
组成、它们与配置控制组的关系以及它们之间的相互关系。本
条还必须说明与特殊产品（如非交付的软件、现存软件、用户
提供的软件和内部支持软件）有关的配置控制规程。
本条必须指明怎样收集、验证、存储、处理和报告配置项
的状态信息。同时，详细说明要定期提供的报告及其分发办法。
如果有动态查询，要指出所提供的动态查询的能力。如果要求
记录用户说明的特殊状态时，要描述其实现手段。
在软件配置管理中，常需要记录和报告以下信息：
a。规格说明的状态；
b。修改建议的状态；
c。修改批准的报告；
d。产品版本或其修改版的状态；
e。安装、更新或交付的实现报告；
f。用户提供的产品（如操作系统）的状态；
g。有关开发项目历史的报告。
3.4 软件配置的检查和评审
本条必须：
a。在软件配置管理计划的第2.2条所定义的软件生命周
期的特定点上执行检查和评审，并说明软件配置管理计划在其
中的作用；
b。规定每次检查和评审所包含的配置项；
c。指出用于标识和解决在检查和评审期间所发现的问题
的工作规程。
4 工具、技术和方法
必须指明为支持特定项目的软件配置管理所使用的软件工
具、技术和方法，指明它们的目的，并在开发者所有权的范围
内描述其用法。例如，可以包括用于下列任务的工具、技术和
方法：
a。软件媒体和媒体文档的标识；
b。将文档和媒体置于软件配置管理的控制之下，并将其
正式交付给用户。例如，要给出对软件库内的源代码和目标代
码进行控制的工具、技术和方法的描述；如果使用数据库管理
系统，则还需对该系统进行描述。又如，要指明如何使用软件
库工具、技术和方法来处理软件产品的交付；
c。编制关于程序及其有关文档的修改状态的文档。因此
必须进一步定义用于准备多种级别（如项目负责人、配置控制
小组、软件配置管理人员和用户）的管理报告的工具、技术和
方法。
5 对供货单位的控制
供货单位是指软件销售单位、软件开发单位或软件子开发
单位。必须规定对这些供货单位进行控制的管理规程，以确保
从软件销售单位购买的、其他开发单位开发的或从开发单位现
存软件库中选用的软件能满足规定的软件配置管理需求。管理
规程应规定在本软件配置管理计划的执行范围内控制供货单位
的方法；还应解释用于确定供货单位的软件配置管理能力的方
法以及监督他们遵循本软件配置管理计划需求的方法。
6 记录的收集、维护和保存
本章必须指明要保存的软件配置管理文档，指明用于汇总、
保护和维护这些文档的方法和设施（其中包括要使用的后备设
施），并指明要保存的期限。
7 附录：配置管理报表及其格式
7.1 软件问题报告单（SPR）
在系统的运行与维护阶段对软件产品的任何修改建议，或
在软件开发的任一阶段中对前面各个阶段的阶段产品的任何修
改建议，都应填入软件问题报告单。软件问题报告单的格式见
表1.
对于任何软件产品或其阶段产品的修改，都必须经过评审
和批准后才能重新投入运行或释放。这个过程需要使用软件修
改报告单（arechangereport）进行记录。表格2是软件修改报
告单的格式。配置管理人员会在收到软件问题报告单后填写软
件修改报告单，其中需要指出修改类型、修改策略和配置状态。
软件修改报告单是供配置控制小组进行审批的修改申请报告。
表格中各项内容的意义如下：
A是登记号，表示配置修改小组收到软件修改报告单时所
作的编号；
B是配置管理人员登记软件修改报告单的日期；
C是已经准备好软件修改报告单、可以对它进行评审的时
间；
D、E和F的意义与软件问题报告单中的D、E和F的意
义相同；
G填写被处理的软件问题报告单的编号，如该编号中提出
的问题只是部分解决，则在填写时要在该编号后附以字母P
（Part表示部分之意）；
H指出是程序修改、文档更新、数据库修改还是它们的组
合。如果仅是指出用户文档的缺陷，则在解释处作上记号；
I是修改的详细描述。如果是文档更新，则需要列出文档
更新通知单的编号。如果是数据库修改，则需要列出数据库修
改申请的标识号；
XXX是批准人，只有经批准人签字并批准后才能进行修
改；
K是语句类型，程序修改中涉及到的语句类型包括：输入
/输出语句类、计算语句类、逻辑控制语句类、数据处理语句
类（如数据传送、存放语句）；
L是程序名，指被修改注程序、文档或数据库注名字。如
果只要求软件修改报告单做解释性工作，则注重复软件问题报
告单给出的名字；
M指当前注版本/修订本标识；
N指修改后的新版本/修订本标识；
O指数据库，如果申请数据库修改，这里给出数据库的标
识符；
P是数据库修改申请号DBCR；
Q指文档，即如果要求文档修改，则在这里给出文档的名
字；
R是文档更新通知单编号DUT；
S表示修改是否已经测试，指出已对修改做了哪些测试，
如单元、子系统、组装、确认和运行测试等，并注明测试成功
与否；
T指出在软件问题报告单中给出的问题描述是否准确，并
回答是或否；
U是问题注释，准确地重新叙述要修改的问题；
V指明问题来自哪里，如系统设计规格说明书、软件需求
规格说明书、概要设计说明书、详细设计说明书、数据库、源
程序等；
W说明完成修改所需要的资源估计，即所需的人月数和
计算机终端时数。
软件配置管理计划编写规范
表1 软件问题报告单（SPR）
登记号：
软件问题报告单登记日期：
发现日期：
项目名：
阶段名：
软件定义：
姓名：
报告人地址：
问题类型（勾选）：例行程序□程序□数据库□文档□改进
□
问题描述/影响：
附注及修改建议：
表2 软件修改报告单（SCR）
登记号：
软件修改报告单登记日期：
发现日期：
项目名：
子项目：
代号：
修改类型（勾选）：适应性修改□改进性修改□计算错误□
逻辑错误□输入和输出错误□接口错误□数据库错误□文档错误
□配置错误□
修改申请人：
修改人：
响应哪些SPR：
修改描述：
批准人：
改动：
SPR的问题叙述准确否？是□否□
附注：
问题来自（勾选）：系统设计规格说明书□需求规格说明
书□设计说明书□数据库□程序□
资源来自：
人工数：（单位：人日）
计算机时间：（单位：小时）
语句类型（勾选）：I/O□计算□逻辑□数据处理□
程序名：
数据库：
修改已测试否：
成功否：
老版本号：
新版本号：
DBCR：
单元子系统：
文档：
组装确认：
DUT：
运行：
发布评论