文件编号：PTS - PDP - SCMP
软件配置管理计划
拟制： 日期：
审核： 日期：
批准： 日期：
xxx软件（中国）有限公司
变更记录页
|
单 位：xxx软件（中国）有限公司，以下简称PTS 文档名称：软件配置管理计划 生成日期：20xx-12-13 |
|||
|
版 本 |
作者 |
日 期 |
备 注 |
软件配置管理计划
1介绍
1.1目的
1.2范围
1.3缩写和定义
2SCM管理
SCM管理信息描述了组织和个人在项目的SCM活动中的责任和权限。
SCM管理信息必须包括三个主题：应用SCM的项目组织，这些组织的SCM责任，以及应用在这个项目中的SCM政策和指令。
2.1组织
组织结构包括技术和管理两方面，计划中的并将要被实施的SCM活动必须被描述。计划必须说明以下问题：
a)在项目中，参与或对任何SCM活动负责的组织单位；
b)在项目结构中，组织单位的功能角色；
c)各组织单位之间的关系。
组织单位可能包括供应商和客户，主承包商和分承包商，或在组织中的其他团队。组织图表、功能和关系的状态的补充可以成为表现信息的有效途径。
2.2SCM责任
对组织单位SCM活动的分配必须被详细说明。对每个在SCM中列出的活动，必须提供执行活动的组织单位或工作标题的名字。可以使用矩阵清楚地表示和说明以上定义的组织和SCM功能、活动和任务之间的关系。
对于那些在项目中为执行SCM活动而建立的任何审查委员会或特定组织，计划中必须描述有关它们的以下方面：
a)目的和目标 ；
b)成员和联系；
c)有效期；
d)权限范围；
e)操作程序。
2.3可用的策略、指令和程序
由其它政策、指令和过程附加在计划上的限制必须被定义。对每一个限制来说，它的影响和效果必须被声明。
3SCM 活动
SCM活动标识了所有在计划范围内，管理软件系统配置所需的功能和任务。技术和管理的SCM活动都必须被标识。通常的SCM实质的项目管理活动必须以SCM观点来描述。
3.1配置标识
配置标识活动必须标识、命名和描述文档的物理和功能特性，其文档包括项目中被控制的代码、规范、审计、和数据元素。获取这些文档用于配置控制。配置项可以作为中间或最终的产品（例如，可执行代码、源代码、用户文档、计划列表、数据库、测试案例、测试计划、规范和管理计划）和支持环境元素（例如，编译器、操作系统、设计工具和测试基础）。
计划必须在每个项目控制点标识项目配置项(CI)和它们的结构。计划必须声明每个CI和它的版本，对定义、追溯、存储和检索的CI活动的执行必须被单独命名和描述。
3.1.1配置项的标识
计划必须记录控制项、项目的CI和它们的定义。计划必须描述项目中维护的项的列表和结构。至少，所有要发布的CI必须都被列出来。
在项目生命周期的控制点，必须定义适当的基线。如下：
a)产生基线的事件；
b)在基线中控制的项；
c)用来建立和改变基线的过程；
d)说明基线文档变更所需的授权；
变更、受影响的CI以及相关联的基线必须被详细说明。
3.1.2配置项的命名
为了对每个控制项分配单独的标识符，计划必须制定和标识系统。同样必须单独指定有多少个版本。标识的方法包括命名约定、版本号和字符。
计划必须描述为存储、检索、跟踪、再生、和分发命名控制项的方法，活动包括为版本标记、为文档和执行标签，为执行芯片内嵌代码或数据排序和改变标记，物理包的标识。
转承包商的软件、供应商所有的软件和支持软件可能需要特殊的标识方案和标记。
3.1.3配置项的获取
计划必须为计划标识受控软件库，描述标识基线的代码、文本和数据如何物理的存放在适当的库中。对每个库来说，格式、位置、文档需求、接受和检查需求和访问控制过程都必须被详细说明。
计划必须为实际上的文档和磁介质的存储指定过程，包括项的物理标记和分类。同样也要说明数据保存过程、灾难预防和恢复过程。
过程必须描述如何从存储库中检索和复制控制项目。这些活动包括标记和分类的确认，受控拷贝的追踪和所有权和安全信息的保护。.
3.2配置控制
配置控制活动请求、评估、认可或拒绝、实现对基线CI的配置变更。变更包括错误的改正和可靠性增强。为变更过程所需的必须手续的复杂程度依靠在配置结构中变更对基线的影响。
计划必须描述在基线CI的变更控制影响。计划必须定义下列的详细步骤：
a)变更所需的标识和文档；
b)变更需求的分析和评估；
c)需求的认可或否决；
d)变更的确认、执行和发布；
计划必须标识用来追踪和记录每个变更的执行序列的记录。在处理原始需求的变更的每个不同必须被明确的记录下来。
3.2.1请求变更
计划必须指定对一个基线CI需求变更和为需求记录信息的过程。至少，一个提交的变更的信息记录必须包括以下几方面：
a)问题出现的CI的名字和版本；
b)开发者的姓名和组织；
c)需要的数据；
d)紧急程度指示；
e)变更所需资源；
f)需要变更的描述；
附加信息，如优先权或分类，可能用来澄清需求的重要意义和帮助分析、评估。其它信息，例如变更需求编号、状态和处理，记录在变更追踪中。
3.2.2评估变更
为了提交变更影响和审阅分析变更结果过程，计划必须指定的它们所需的分析。变更必须依照它们对交付程度和项目资源的影响来衡量。
3.2.3批准或拒绝变更
计划必须标识每个配置控制委员会（CCB）和他们的可授权或认可提交变更的等级。一个（CCB）可以是个人也可以是组织。根据系统等级或项目的复杂程度或涉及的项目基线，可以指定CCB的多重层次。但使用一个多重CCB时，在项目生命周期中，包括所有变量，计划必须指定如何决定一个变更需求的范围。
对任何CCB应用，计划必须指明授权的等级和定义的责任。
3.2.4实施变更
计划必须指定一个认可变更指定校验和实现的活动。为变更完成记录的信息必须包括以下几点：
a)相关变更的需求；
b)影响的项目的名字和版本；
c)确认日期和责任人；
d)发布或安装日期和责任人；
e)新版本的标识。
附加信息，例如软件默认规则或用来实现变更的支持软件，不包括在内。
计划必须为发布计划和控制指定活动，例如，协调多重变更，再配置CI和发布一个新基线。
3.3配置状态统计
配置状态统计活动记录和报告项目CI的状态。计划必须包括以下信息：
a)为了基线和变更，哪些数据元素被追踪和报告了；
b)生成了哪种状态统计报告类型，和它们的频率；
c)信息怎样被收集、存储、处理和报告；
d)受控的如何访问状态数据。
如果一个自动系统作为状态统计活动，必须描述或引用它的功能。
对每个CI，至少下列数据元素必须追踪和报告：它的初始化认可版本，请求变更的状态和认可变更的实现状态。细节的级别和需求的特定数据可能因为项目和客户的信息需求而变化。
3.4配置审核和审计
配置审核决定事实上CI影响的所需的物理和功能的广度。配置审阅时建立基线的管理工具。
计划必须为项目标识配置审核和审计。至少，一个配置审核必须在CI发布前审核。
对每个计划的配置审核和审计，计划必须定义以下方面：
a)它的目标；
b)处于审核和评审CI；
c)审核和评审任务的时间表；
d)实施审核和评审的过程；
e)工作标题的参与者；
f)为回顾或支持审核和评审需要用到的文件；
g)记录不足和报告纠正行动的过程；
h)对认可之外的认可标准和特定行动。
3.5接口控制
接口控制活动协调项目CI变更和计划范围外的接口项变更。硬件、系统软件和支持软件和其他项目和交付都必须检查，以控制对项目的潜在接口影响。
计划必须标识对项目软件接口的外部项。对每个接口计划必须如下定义：
a)接口的本质；
b)影响的组织；
c)接口的代码、文档和数据被如何控制；
d)界面控制文档被如何认可和发布为特定基线
对每个CCB建立控制接口，计划必须标示它的责任和过程。
3.6转包商/供应商控制
转包商/供应商控制活动合并项在项目CI的环境之外发展。包括订合同的软件开发和项目中第三方软件。由于组织和法律关系，特别的注意必须直接指向SCM活动。
对每一个转包商和第三方的软件，计划必须定义活动以合并外部开发项到项目CI中，和与它们的开发组织协调变更。
对每个转包商的软件，计划必须如下定义：
a)包括SCM计划，什么样的SCM的需求是转包商协议的一部分；
b)怎么为一致性监督转包商；
c)实行了转包商的什么配置审核和复核；
d)怎么用项目软件测试、校验和合并外部代码、文档和数据；
e)处于信息安全和所有权的可追踪性，怎么处理所有的项；
f)包括转包商，如何处理变更。
为第三方的软件，计划必须描述软件如何在SCM下被接受，测试和放置；如何处理对厂商软件的变更；厂商是否和怎样参与项目变更管理过程。第三方软件可能从供应商、转包商、客户、其它项目或其它途径。
4进度安排
SCM时间表信息建立了为标识SCM活动的顺序和协调，以及为所有事件影响的计划的实现。
对项目里程碑和事件来说，在所有的SCM活动和关键SCM活动中，计划必须声明顺序和从属性。时间表必须覆盖计划和与项目有关的SCM活动的所有主要里程碑的这段时间。SCM里程碑必须包括配置基线的建立，变更控制过程的实现和配置审核的开始和结束日期。
时间表信息必须被表达为完全的日期，对SCM或项目里程碑，或事件简单序列的方式。图形表示方式可以非常适当的传达这些信息。
5 SCM 资源
SCM资源信息标识为特定的SCM活动的实现所需的软件工具、技术、装备、人员和必要培训。
SCM可以用软件工具和手工的过程实现。工具可以是专门为SCM设计的或内嵌于普通项目支援工具中；它们可以是标准组织资源或为该项目专门得到、建立的资源。工具可以应用在库结构和访问控制，文档开发和追踪，基线系统生成，变更处理、通讯和授权中，变更/问题追踪和状态报告，受控项的归档、保存和恢复，或SCM计划处理本身。
对每个软件工具，无论是在项目中开发的或在项目外取得，计划必须描述和引用它的功能，标识工具中放置的配置控制。
6SCM计划维护
SCM计划维护信息标识行为和责任必要，以在项目的生命周期中确定持续的SCM计划。计划必须标识以下方面：
a)谁对监视计划负责；
b)更新以怎样的频率进行；
c)对计划的变更如何衡量和认可；
d)对计划的变更如何构造和通讯。
计划必须在每个软件项目阶段的开始审阅，然后变更、认可和分发到项目组中。
如果在其它地方如附录或参考，计划已经用详细的记录过程作了构造，为那些过程作的不同的维护机制可能是适当的。
第二篇：ISO软件开发文档模板_配置管理计划模板
公司徽标
产品/项目系统名称
配置管理计划
XXXX有限公司
200 年××月
公司徽标
1引言
1.1编写目的
编写的目的主要在于对所开发的软件系统规定各种必要的配置管理条款，以保证所开发出的软件能满足用户需求。
1.2背景
a.开发的软件系统的名称
列出本软件系统的中文全称、英文全称及英文表示简称。 b.开发的软件系统的最终用户或适用的领域；
c.项目来源、主管部门等
1.3定义
列出本文件中涉及的专门术语定义和外文缩写的原词组。
1.4参考资料
列出涉及的参考资料。
2 管理
描述软件配置管理的机构、任务、职责和有关的接口控制。
2.1 机构
描述软件生存周期中各阶段中软件配置管理的功能和负责软件配置管理的机构。
说明项目和自项目与其他有关项目之间的关系。
公司徽标
指出在软件生存周期各阶段中的软件开发或维护机构与配置控制组的关系。
2.2 任务
描述在软件生存周期中各阶段的配置管理任务以及要进行的评审和检查工作，并指出各阶段的阶段产品应存放在哪一类软件库中（软件开发库、软件受控制库或软件产品库）。
2.3 职责
指出负责各项软件配置管理任务（如配置标识、配置控制、配置状态记录以及配置的评审与检查）的机构的职责；
指出上述机构与软件质量保证机构、软件开发单位、项目承办单位、项目委托单位以及用户等机构的关系。
说明软件生存周期各个阶段的评审、检查和审批过程中的用户职责以及相关的开发与维护活动。
指出与项目开发有关的各机构的代表的软件配置管理职责。
指出与其他特殊职责，例如为满足软件配置管理要求所必要的批准要求。
2.4 定义软件配置项（SCI）
包括：
1． 系统约定
2． 软件项目计划
公司徽标
3． 软件需求文档
4． 用户手册
5． 设计文档
6． 源代码清单
7． 测试文档
a.
b. 测试计划和过程 测试用例和结果记录
8． 可执行程序
a.
b. 模块的可执行代码 链接的模块
9． 数据库描述
a.
b. 模式和文件结构 初始内容
10． 联机用户手册
11． 维护文档
a.
b.
c. 软件问题报告 维护记录 工程变化
12． 软件工程的标准和规程
2.5 软件配置管理计划的实现
公司徽标
规定实现软件配置管理计划的主要里程碑，例如：
建立配置控制组
确定各个配置基线
建立接口控制协议
指定评审与检查软件配置管理计划和规程
制定相关的软件开发、测试和支持工具的配置管理计划和规程
2.6 适用的标准、条例和约定
可包括如下内容：
软件结构层次树中软件位置的标识方法；
程序和模块的命名约定；
版本级别的命名约定；
软件产品的标识方法；
规格说明、测试计划与测试规程、程序设计手册及其他文档的标
识方法；
媒体和文档管理的标识方法；
文档交付过程；
软件产品库中软件产品入库、移交或交付的过程；
问题报告、修改请求或修改次序的处理过程；
配置控制组的结构和作用；
软件产品交付给拥护的验收规程
公司徽标
软件库的操作，包括准备、存储和更新模块的方法；
软件配置管理活动的检查；
问题报告、修改请求或修改次序的文档要求，指出配置修改的目的和影响；
软件进入配置管理之前的测试级别；
质量保证级别，例如：在进入配置管理之前，验证软件满足有关基线的程度。
3 软件配置管理活动
描述配置标识、配置控制、配置状态记录与报告以及配置检查与评审等4方面的软件配置管理活动的需求。
3.1 配置标识
3.1.1说明软件项目的基线，包括：功能基线、指派基线和产品基线。对于每个基线，必须描述以下内容：
每个基线的项（包括应交付的文档和程序）
与每个基线有关的评审与批准事项以及验收标准
在建立基线的过程中用户与开发者的参与情况
例如在产品基线中，要定义的项可以包括：
a. 产品的名字和命名规则；
b. 产品标识编号；
c. 对每个新交付的版本，要给出版本交付号、新修改的描述、
公司徽标
修改交付的方法、对支持软件的修改要求以及对有关文档的
修改要求。
d. 安装说明；
e. 已知的缺陷和故障；
f. 软件媒体和媒体标识。
3.1.2描述本项目所有软件代码和文档的标题、代号、编号以及分类规程。例如，对于代码：编译日期可以作为每个交付模块标识的一部分。
3.2 配置控制
描述在本计划2.2条描述软件生存周期中各阶段使用的修改批准权限的级别。
定义对已有配置的修改建议进行处理的方法，其中包括：
a. 详细说明在本计划2.2条描述的软件生存周期各阶段中提出的修改建议的程序（可以用注上自然语言的流程图来表达）
b. 描述实现已经批准的修改建议（包括源代码和文档的修改）的方法；
c. 描述软件库控制的规程，其中包括存取控制、对适用基线的读写保护、成员保护、成员标识、档案维护、修改历史以及
故障恢复等7项规程；
对于不同层次的配置控制组和其他修改管理机构，应定义其作用，
公司徽标
并规定其权限和职责；如果已组成机构，则指明该机构的领导人和成员；如果还没有成立机构，那么说明怎样任命该机构的领导人、成员和代理人；说明开发者和用户与配置控制组的关系；
当要与不属于本软件配置管理计划适用范围的程序和项目进行接口时，本条必须说明对其进行配置控制的方法。如果这些软件的修改需要其他机构在配置控制组评审之前或之后进行评审，则必须描述这些机构的组成、它们与配置控制组的关系以及它们之间的相互关系。
必须说明与特殊产品（如非交付的软件、现存软件、用户提供的软件和内部支持软件）有关的配置控制规程。
3.3 配置状态的记录和报告
必须指明怎样收集、验证、存储处理和报告配置项的状态信息； 详细说明要定期提供的报告及其分发办法；
如果有动态查询，要指出所提供的动态查询的能力；
如果要记录用户说明的特殊状态时，要描述其实现手段。
例如，在配置状态记录和报告中，通常要描述的信息有：
a. 规格说明的状态
b. 修改建议的状态
c. 修改批准的报告
d. 产品版本或其修改版的状态
e. 安装、更新或交付的实现报告
公司徽标
f. 用户提供的产品（如操作系统）的状态
g.有关开发项目历史的报告
3.4 配置的检查和评审
定义在软件配置管理计划的2.2条所定义的软件生存周期的特定点上执行的检查和评审中软件配置管理计划的作用。
规定每次检查和评审所包含的配置项。
指出用于标识和解决在检查和评审期间所发现的问题的工作规程。
4 工具、技术和方法
指明为支持特定项目的软件配置管理所使用的软件工具、技术和方法，指明它们的目的，并在开发者所有权的范围内描述其用法。例如，可以包括用于下列任务的工具、技术和方法：
a.软件媒体和媒体文档的标识。
b.把文档和媒体置于软件配置管理的控制之下，并把它正式地交付给用户。例如要给出对软件库内的源代码进行控制的工具、技术和方法的描述；如果用到数据库管理系统，则还要对该系统进行描述。又如，要指明怎样使用软件库工具、技术和方法来处理软件产品的交付。
c.编制关于程序及有关文档的修改状态的文档。因此必须进一步定义用于准备多种级别（如项目负责人、配置控制小组、软件配置管
公司徽标
理人员和用户）的管理报告的工具、技术和方法。
5 对供货单位的控制
供货单位是指软件销售单位、软件开发单位或软件子开发单位。必须规定对这些供货单位进行控制的管理规程，从而使从软件销售单位购买的、其他开发单位开发的或从开发单位现存软件库中选用的软件能满足规定的软件配置管理需求。管理规程应规定在本软件配置管理计划的执行范围内控制供货单位的方法；还应解释用于确定供货单位的软件配置管理能力的方法以及监督他们遵循本软件配置管理计划需求的方法。
6 记录的收集、维护和保存
指明要保存的软件配置管理文档，指明用于汇总、保护和维护这些文档的方法和设施（其中包括要使用的后备设施），并指明要保存的期限。