软件配置管理计划模版

文件编号：PTS - PDP - SCMP
软件配置管理计划
拟制：____________________ 日期：____________________ 审核：____________________ 日期：____________________ 批准：____________________ 日期：____________________
太平洋软件（中国）有限公司
变更记录页
单位：太平洋软件（中国）有限公司，以下简称PTS
文档名称：软件配置管理计划
生成日期：2002-12-13
版本作者日期备注
目录
1介绍 (1)
1.1 目的 (1)
1.2 范围 (1)
1.3 缩写和定义 (1)
2SCM管理 (2)
2.1 组织 (2)
2.2 SCM责任 (2)
2.3 可用的策略、指令和程序 (2)
3SCM 活动 (3)
3.1 配置标识 (3)
3.1.1 配置项的标识 (3)
3.1.2 配置项的命名 (3)
3.1.3 配置项的获取 (3)
3.2 配置控制 (4)
3.2.1 请求变更 (4)
3.2.2 评估变更 (4)
3.2.3 批准或拒绝变更 (5)
3.2.4 实施变更 (5)
3.3 配置状态统计 (5)
3.4 配置审核和审计 (6)
3.5 接口控制 (6)
3.6 转包商/供应商控制 (6)
4进度安排 (8)
5SCM 资源 (8)
6SCM计划维护 (8)
软件配置管理计划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或项目里程碑，或事件简单序列的方式。

图形表示方式可以非常适当的传达这些信息。

5SCM 资源
SCM资源信息标识为特定的SCM活动的实现所需的软件工具、技术、装备、人员和必要培训。

SCM可以用软件工具和手工的过程实现。

工具可以是专门为SCM设计的或内嵌于普通项目支援工具中；它们可以是标准组织资源或为该项目专门得到、建立的资源。

工具可以应用在库结构和访问控制，文档开发和追踪，基线系统生成，变更处理、通讯和授权中，变更/问题追踪和状态报告，受控项的归档、保存和恢复，或SCM计划处理本身。

对每个软件工具，无论是在项目中开发的或在项目外取得，计划必须描述和引用它的功能，标识工具中放置的配置控制。

6SCM计划维护
SCM计划维护信息标识行为和责任必要，以在项目的生命周期中确定持续的SCM计划。

计划必须标识以下方面：
a)谁对监视计划负责；
b)更新以怎样的频率进行；
c)对计划的变更如何衡量和认可；
d)对计划的变更如何构造和通讯。

计划必须在每个软件项目阶段的开始审阅，然后变更、认可和分发到项目组中。

如果在其它地方如附录或参考，计划已经用详细的记录过程作了构造，为那些过程作的不同的维护机制可能是适当的。

8/11。