软件配置管理计划模版

1、文件编号：PTS - PDP - SCMP 软件配置管理计划 拟制：_ 日期：_ 审核：_ 日期：_ 批准：_ 日期：_ 太平洋软件（中国）有限公司 变更记录页变更记录页 单单 位：位：太平洋软件（中国）有限公司，以下简称 PTS 文档名称：文档名称：软件配置管理计划 生成日期：生成日期：2002-12-13 版版 本本作者作者日日 期期备备 注注 目录 1介绍介绍.2 1.1目的.2 1.2范围.2 1.3缩写和定义.2 2SCM 管理管理.2 2.1组织.2 2.2SCM 责任.2 2.3可用的策略、指令和程序.2 3SCM 活动活动.2 3.1配置标识.2 3.1.1配置项的标识.2 3

2、.1.2配置项的命名.2 3.1.3配置项的获取.2 3.2配置控制.2 3.2.1请求变更.2 3.2.2评估变更.2 3.2.3批准或拒绝变更.2 3.2.4实施变更.2 3.3配置状态统计.2 3.4配置审核和审计.2 3.5接口控制.2 3.6转包商/供应商控制 .2 4进度安排进度安排.2 5SCM 资源资源.2 6SCM 计划维护计划维护.2 软件配置管理计划软件配置管理计划 1介绍介绍 1.1目的目的 1.2范围范围 1.3缩写和定义缩写和定义 2SCM 管理管理 SCM 管理信息描述了组织和个人在项目的 SCM 活动中的责任和权限。 SCM 管理信息必须包括三个主题：应用 SC

3、M 的项目组织，这些组织的 SCM 责任，以 及应用在这个项目中的 SCM 政策和指令。 2.1组织组织 组织结构包括技术和管理两方面，计划中的并将要被实施的 SCM 活动必须被描述。 计划必须说明以下问题： a)在项目中，参与或对任何 SCM 活动负责的组织单位； b)在项目结构中，组织单位的功能角色； c)各组织单位之间的关系。 组织单位可能包括供应商和客户，主承包商和分承包商，或在组织中的其他团队。组 织图表、功能和关系的状态的补充可以成为表现信息的有效途径。 2.2SCM 责任责任 对组织单位 SCM 活动的分配必须被详细说明。对每个在 SCM 中列出的活动，必须提 供执行活动的组织单

4、位或工作标题的名字。可以使用矩阵清楚地表示和说明以上定义的组 织和 SCM 功能、活动和任务之间的关系。 对于那些在项目中为执行 SCM 活动而建立的任何审查委员会或特定组织，计划中必须 描述有关它们的以下方面： a)目的和目标 ； b)成员和联系； c)有效期； d)权限范围； e)操作程序。 2.3可用的策略、指令和程可用的策略、指令和程序序 由其它政策、指令和过程附加在计划上的限制必须被定义。对每一个限制来说，它的 影响和效果必须被声明。 3SCM 活动活动 SCM 活动标识了所有在计划范围内，管理软件系统配置所需的功能和任务。技术和管 理的 SCM 活动都必须被标识。通常的 SCM 实

5、质的项目管理活动必须以 SCM 观点来描述。 3.1配置标识配置标识 配置标识活动必须标识、命名和描述文档的物理和功能特性，其文档包括项目中被控 制的代码、规范、审计、和数据元素。获取这些文档用于配置控制。配置项可以作为中间 或最终的产品（例如，可执行代码、源代码、用户文档、计划列表、数据库、测试案例、 测试计划、规范和管理计划）和支持环境元素（例如，编译器、操作系统、设计工具和测 试基础） 。 计划必须在每个项目控制点标识项目配置项(CI)和它们的结构。计划必须声明每个 CI 和它的版本，对定义、追溯、存储和检索的 CI 活动的执行必须被单独命名和描述。 3.1.1 配置项的标识配置项的标识

6、 计划必须记录控制项、项目的 CI 和它们的定义。计划必须描述项目中维护的项的列表 和结构。至少，所有要发布的 CI 必须都被列出来。 在项目生命周期的控制点，必须定义适当的基线。如下： a)产生基线的事件； b)在基线中控制的项； c)用来建立和改变基线的过程； d)说明基线文档变更所需的授权； 变更、受影响的 CI 以及相关联的基线必须被详细说明。 3.1.2 配置项的命名配置项的命名 为了对每个控制项分配单独的标识符，计划必须制定和标识系统。同样必须单独指定 有多少个版本。标识的方法包括命名约定、版本号和字符。 计划必须描述为存储、检索、跟踪、再生、和分发命名控制项的方法，活动包括为版

7、本标记、为文档和执行标签，为执行芯片内嵌代码或数据排序和改变标记，物理包的标识。 转承包商的软件、供应商所有的软件和支持软件可能需要特殊的标识方案和标记。 3.1.3 配置项的获取配置项的获取 计划必须为计划标识受控软件库，描述标识基线的代码、文本和数据如何物理的存放 在适当的库中。对每个库来说，格式、位置、文档需求、接受和检查需求和访问控制过程 都必须被详细说明。 计划必须为实际上的文档和磁介质的存储指定过程，包括项的物理标记和分类。同样 也要说明数据保存过程、灾难预防和恢复过程。 过程必须描述如何从存储库中检索和复制控制项目。这些活动包括标记和分类的确认， 受控拷贝的追踪和所有权和安全信息

8、的保护。. 3.2配置控制配置控制 配置控制活动请求、评估、认可或拒绝、实现对基线 CI 的配置变更。变更包括错误的 改正和可靠性增强。为变更过程所需的必须手续的复杂程度依靠在配置结构中变更对基线 的影响。 计划必须描述在基线 CI 的变更控制影响。计划必须定义下列的详细步骤： a)变更所需的标识和文档； b)变更需求的分析和评估； c)需求的认可或否决； d)变更的确认、执行和发布； 计划必须标识用来追踪和记录每个变更的执行序列的记录。在处理原始需求的变更的 每个不同必须被明确的记录下来。 3.2.1 请求变更请求变更 计划必须指定对一个基线 CI 需求变更和为需求记录信息的过程。至少，一个

9、提交的变 更的信息记录必须包括以下几方面： a)问题出现的 CI 的名字和版本； b)开发者的姓名和组织； c)需要的数据； d)紧急程度指示； e)变更所需资源； f)需要变更的描述； 附加信息，如优先权或分类，可能用来澄清需求的重要意义和帮助分析、评估。其它 信息，例如变更需求编号、状态和处理，记录在变更追踪中。 3.2.2 评估变更评估变更 为了提交变更影响和审阅分析变更结果过程，计划必须指定的它们所需的分析。变更 必须依照它们对交付程度和项目资源的影响来衡量。 3.2.3 批准或拒绝变更批准或拒绝变更 计划必须标识每个配置控制委员会（CCB）和他们的可授权或认可提交变更的等级。 一个（

10、CCB）可以是个人也可以是组织。根据系统等级或项目的复杂程度或涉及的项目基 线，可以指定 CCB 的多重层次。但使用一个多重 CCB 时，在项目生命周期中，包括所有 变量，计划必须指定如何决定一个变更需求的范围。 对任何 CCB 应用，计划必须指明授权的等级和定义的责任。 3.2.4 实施变更实施变更 计划必须指定一个认可变更指定校验和实现的活动。为变更完成记录的信息必须包括 以下几点： a)相关变更的需求； b)影响的项目的名字和版本； c)确认日期和责任人； d)发布或安装日期和责任人； e)新版本的标识。 附加信息，例如软件默认规则或用来实现变更的支持软件，不包括在内。 计划必须为发布计

11、划和控制指定活动，例如，协调多重变更，再配置 CI 和发布一个新 基线。 3.3配置状态统计配置状态统计 配置状态统计活动记录和报告项目 CI 的状态。计划必须包括以下信息： a)为了基线和变更，哪些数据元素被追踪和报告了； b)生成了哪种状态统计报告类型，和它们的频率； c)信息怎样被收集、存储、处理和报告； d)受控的如何访问状态数据。 如果一个自动系统作为状态统计活动，必须描述或引用它的功能。 对每个 CI，至少下列数据元素必须追踪和报告：它的初始化认可版本，请求变更的状 态和认可变更的实现状态。细节的级别和需求的特定数据可能因为项目和客户的信息需求 而变化。 3.4配置审核和配置审核和

12、审计审计 配置审核决定事实上 CI 影响的所需的物理和功能的广度。配置审阅时建立基线的管理 工具。 计划必须为项目标识配置审核和审计。至少，一个配置审核必须在 CI 发布前审核。 对每个计划的配置审核和审计，计划必须定义以下方面： a)它的目标； b)处于审核和评审 CI； c)审核和评审任务的时间表； d)实施审核和评审的过程； e)工作标题的参与者； f)为回顾或支持审核和评审需要用到的文件； g)记录不足和报告纠正行动的过程； h)对认可之外的认可标准和特定行动。 3.5接口控制接口控制 接口控制活动协调项目 CI 变更和计划范围外的接口项变更。硬件、系统软件和支持软 件和其他项目和交付

13、都必须检查，以控制对项目的潜在接口影响。 计划必须标识对项目软件接口的外部项。对每个接口计划必须如下定义： a)接口的本质； b)影响的组织； c)接口的代码、文档和数据被如何控制； d)界面控制文档被如何认可和发布为特定基线 对每个 CCB 建立控制接口，计划必须标示它的责任和过程。 3.6转包商转包商/供应商控制供应商控制 转包商/供应商控制活动合并项在项目 CI 的环境之外发展。包括订合同的软件开发和 项目中第三方软件。由于组织和法律关系，特别的注意必须直接指向 SCM 活动。 对每一个转包商和第三方的软件，计划必须定义活动以合并外部开发项到项目 CI 中， 和与它们的开发组织协调变更。

14、 对每个转包商的软件，计划必须如下定义： a)包括 SCM 计划，什么样的 SCM 的需求是转包商协议的一部分； b)怎么为一致性监督转包商； c)实行了转包商的什么配置审核和复核； d)怎么用项目软件测试、校验和合并外部代码、文档和数据； e)处于信息安全和所有权的可追踪性，怎么处理所有的项； f)包括转包商，如何处理变更。 为第三方的软件，计划必须描述软件如何在 SCM 下被接受，测试和放置；如何处理对 厂商软件的变更；厂商是否和怎样参与项目变更管理过程。第三方软件可能从供应商、转 包商、客户、其它项目或其它途径。 4进度进度安排安排 SCM 时间表信息建立了为标识 SCM 活动的顺序和协

15、调，以及为所有事件影响的计划 的实现。 对项目里程碑和事件来说，在所有的 SCM 活动和关键 SCM 活动中，计划必须声明顺 序和从属性。时间表必须覆盖计划和与项目有关的 SCM 活动的所有主要里程碑的这段时 间。SCM 里程碑必须包括配置基线的建立，变更控制过程的实现和配置审核的开始和结束 日期。 时间表信息必须被表达为完全的日期，对 SCM 或项目里程碑，或事件简单序列的方 式。图形表示方式可以非常适当的传达这些信息。 5 SCM 资源资源 SCM 资源信息标识为特定的 SCM 活动的实现所需的软件工具、技术、装备、人员和 必要培训。 SCM 可以用软件工具和手工的过程实现。工具可以是专门为 SCM 设计的或内嵌于普 通项目支援工具中；它们可以是标准组织资源或为该项目专门得到、建立的资源。工具可 以应用在库结构和访问控制，文档开发和追踪，基线系统生成，变更处理、通讯和授权中， 变更/问题追踪和状态报告，受控项的归档、保存和恢复，或 SCM 计划处理本身。 对每个软件工具，无论是在项目中开发的或在项目外取得，计划必