软件配置管理系统要求规范
软件配置管理规范
1.简介
软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。
1.1 目的
本文档指导项目开展配置管理活动。
1.2 范围
本文档适用于SWL开发小组批准立项的软件项目。
1.3 文档结构
第一部分：
简介，包括本规范的目的、范围、词汇以及所涉及到的参考信息。
第二部分：
配置管理工作规范的正文，包括活动的流程图、进入能及退出的准则、所涉及的角色、相
关活动的阐述、验证与确认能及度量。
第三部分：
变更控制工作规范的正文，包括活动的流程图、进入能及退出准则、所涉及的角色、相关
活动的阐述、验证与确认能及度量。
第四部分：
参考文献，列出了编写本规范所参考的相关的文献资料。
第五部分：
附录，本文中流程图的标准符号定义。
1.4 词汇表
CM (Configuration Management)
配置管理。
CCB (Change Control Board)
变更控制委员会。
CI (Configuration Item)
配置项，包含文档、程序。
CR (Change Request)
变更请求，对提出的要变更工件或流程的任何请求的统称。在变更请求中记录的信息
是有关当前问题、提议解决方案及其成本的起源和影响的信息。
PCA (Physical Configuration Audit)
物理审计，在配置管理系统中建成立基线的工件是否为“正确”版本。
FCA (Functional Configuration Audit)
功能审计，核心软件配置项的实际性能是否符合它的需求。
基线 (Baseline)
己通过复审和批准的工件发布版，由此构成进一步演进或开发的公认基础，并且只能
通过正式程序，例如变更管理和配置控制才能进行更改。
CML (Configuration Management Library)
配置客理库，存储项目工件的所有版本，即存储项目的定义的配置项。
版本 (Version)
某个工件的变体，工件的后期版本一般是在初期版本的基础上进行的扩展。
1.5参考信息
1.5.1 可追溯性
CMU/ SET-93-TR-024 Capability Maturity Model SM for Software, Version 1.1 1.5.2 方针
SWL开发组项目开发与管理工作方针
1.5.3 过程/规范
项目计划与控制规范
1.5.4 指南
配置管理计划指南
基线策略指南
配置状态报告编制指南
配置审计工作活动指南
配置管理工具指南
VSS 使用指南
组织管理配置库使用指南
软件开发文档命名约定
1.5.5模板
配置管理计划
配置状态报告
配置审计报告
文档变更请求
1.5.6 检查表
无
1.5.7 培训
《软件配置管理教材》
《软件变更控制管理教材》
《Clear Case 配置管理培训教材》
1.5.7 工具
Clear Case
Visual SourceSafe
Visual Basic
Office 97/2000/XP
DreamWeaver
PhotoShop
Microsoft SQL Server 2000
1.6 参考网站
1．配置管理规范
2.1 配置管理流程图
2.2 角色
本文档在组织中实施所涉及的角色
进入准则
2.4 输入
2.6 输出
验证与确认
2.9 度量
2．变更控制规范3.1 变更控制流程图
3.2 角色
进入准则
3.4 输入
3.5 活动
3.8 退出准则
3.8 度量
3．参考文献
[BUC93]
Implementing Configuration Management,Hardware,Software and Firmware,Los Almitox,CA:IEEE Computer Science Press,j.Buckley 1993.
[Rational 2001]
Rational Unified Process,Version2001,Rational Software Corporation,2001. [SCM_CRI_2.0]
软件配置管理规范，托普信息集团，2002
附录
附录A —流程框图符号
Parallelograms represent Inputs and Output to
or from a process/procedure.
Rectangles represent individual process/procedure activities
Lines with arrowheads connect symbols to show
the progression or directionof he activities.
Diamonds represent important decision points in
the process/procedure.
Circles represent connectors when a process/procedure flowchart continues on the next page
附录B —文档命名指南
根据软件工程文档命名规则GB8567中的建议，文档命名采用以下规则：文档命名由两部分构成，格式如下：
Project_filename.XXX
其中解释如下：
Project代表项目名称的简写，一般不超过6个安符
Filename.XXX是文件名称
Version代表版本号
例如：
SWL_SCMPlan.doc代表的意义如下：SWL项目组的软件配置计划
.
配置管理规程
配置管理（Configuration Management, CM）的目的是通过执行版本控制、变更控制等规程，以及使用配置管理软件，来保证所有配置项的完整性和可跟踪性。 配置管理过程域的四个主要规程： 制定配置管理计划－配置库管理－配置版本控制－配置变更控制 定义 1.工作成果（Work Product） 项目研发和管理过程中会产生许许多多的工作成果，例如文档、程序和数据等。 2.配置项（Configuration Item, CI） 所有纳入配置管理范畴的工作成果统称为配置项，配置项主要有两大类： （1）属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等。 （2）项目管理中产生的文档。如计划、报告等。这些文档虽然不是产品的组成部分，但是值得保存。 每个配置项的主要属性有：标识符、名称、文件状态、版本、作者、日期等。所有配置项都须保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 3.基线（Baseline） 基线由一组配置项组成，并且这些配置项已被“冻结”，任何人不能再随意修改（见变更控制规程）。基线通常在里程碑处建立，所以一个产品可以有一个或多个基线。基线的主要属性有：标识符、名称、版本、日期等。通常将交付给客户的基线称为一个“Release”，为内部开发所用的基线则称为一个“Build”。 4.项目配置管理员（Project Configuration Manager） 为了提高配置管理的效率和安全性，项目需要有专人为项目制定《配置管理计划》，创建和维护配置库，在本文档中，该负责人称为项目配置管理员。在公司，项目支持负责人担任项目配置管理员的角色。 5.项目变更控制委员会（Change Control Board, CCB） 项目CCB对项目内配置管理的各项活动拥有决策权（例如审批配置管理计划，审批变更请求等）。对于配置管理而言，项目CCB是决策者，而项目配置管理员是执行者。项目CCB的人数视项目的规模而定。通常项目CCB由项目经理、资深项目成员等人组成，项目经理为项目CCB负责人。CCB的决策采用“少数服从多数”原则。 1.1 配置管理流程介绍 配置管理的流程下图所示：
软件开发项目配置管理工具的选择
软件开发项目配置管理工具的选择 通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报…… 每一个软件项目，无论是工程类项目，还是产品类项目，都必须经历需求分析、系统设计、编码实现、集成测试、部署、交付、维护和支持的过程。在这个过程中，将生成各种各样不同的工件，包括文档、源程序、可执行代码、支持库。更可怕的是，频繁出现的变更是不可避免的，因此面向如此庞大且不断变动的信息集，如何使其有序、高效地存放、查找和利用就成为了一个突出的问题。 针对这一问题，最早的开发人员尝试过的解决办法是通过手工来实现： 1)文档：每次修改时都另存为一个新的文件，然后通过文件名进行区分，例如"XXX 软件需求说明书V1.0，XXX软件需求说明书V1.1，XXX 软件需求说明书V2.0."，并且在文件中注明每次版本变化的内容； 2) 源代码：每次要修改时就将整个工程目录复制一份，将原来的文件夹进行改名，例如"XX 项目V1.0、XX 项目1.01、."，然后在新的目录中进行修改； 但是这种方法，不仅十分繁琐，容易出错，而且会带来大量的垃圾数据。如果是团队协同开发或者是项目规模较大时，还是会造成很大的混乱。很显然，这样简陋的方法是无法应对这一问题的。后来，有人尝试从制造工业领域引入了"配置管理"这一概念，通过不懈的研究与实践，最终形成了一套管理办法和活动原则，这也就是软件配置管理。 通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报。 常见的配置管理工具 正如前面所述，由于软件配置管理过程十分繁杂，管理对象错综复杂，如果是采用人工的办法不仅费时费力，还容易出错，产生大量的废品。因此，引入一些自动化工具是十分有裨益的，这也是做好配置管理的必要条件。 正是因为如此，市场上出现了大量的自动化配置管理工具，这些工具的实现原理与基本机制
16软件配置管理报告
份号：001 密级： XXXXXXXX项目 软件配置管理报告 XXXX-RPB-R01.00 XXXXXXXX公司 XXXX年XX月XX日
辑要页
文档修改记录
目次 1 范围 (1) 1.1标识 (1) 1.2系统概述 (1) 1.3文档概述 (1) 2 引用文挡 (1) 3 软件配置管理情况综述 (1) 4 软件配置管理基本信息 (1) 5 专业组划分及权限分配 (1) 6 配置项记录 (1) 7 变更记录 (2) 8 基线记录 (2) 9 入库记录 (2) 10 出库记录 (2) 11 审核记录 (2) 12 备份记录 (2) 13 测量 (2) 14 主释 (2)
1 范围 1.1 标识 本条应描述本文档所适用的系统和软件的完整标识，适用时，包括其标识号、名称、缩略名、版本号和发布号。 1.2 系统概述 本条应概述本文档所适用的系统和软件的用途。它还应描述系统与软件的一般特性;概述系统开发、运行和维护的历史;标识项目的需方、用户、开发方和保障机构等;标识当前和计划的运行现场;列出其他有关文档。 1.3 文档概述 本条应概括本文档的用途和内容，并描述与其使用有关的保密性考虑。 2 引用文挡 本章应列出引用文档的编号、标题、编写单位、修订版及日期，还应标识不能通过正常采购活动得到的文档的来源。 3 软件配置管理情况综述 本章应描述软件配置管理活动进展，与软件配置管理计划的偏差;软件配置管理活动与规程是否相符;对不符合项所采取的措施;完成软件配置管理工作的工作量等。 4 软件配置管理基本信息 本章应概述软件配置管理的基本信息，包括项目负责人、各级软件配置管理机构组成人员和负责人、软件配置管理所用的资源(如计算机、软件和工具)等。 5 专业组划分及权限分配 本章应列出项目专业组的划分、各专业组的成员以及各成员的权限分配，如专业组可分为项目负责人、开发组、测试组、质量保证组、配置管理组等，权限可分为读出、增加、替换、删除等。 6 配置项记录 本章所列出项目的所有配置项，包括配置项名称、配置项最后发布日期、配置项控制力度(控制力度可分为基线管理、非基线管理(受到管理和控制))、配置项版本变更历史、配置项变更累计次数等内容。
软件配置管理计划
软件配置管理计划 案卷号 日期 ,项目名称, 软件配置管理计划 作者: 完成日期: 签收人: 签收日期: 修改情况记录: 版本号修改批准人修改人安装日期签收人 目录 1 引 言 ..................................................................... ........ 1 1.1 目的..................................................................... 1 1. 2 定义和缩写 词 ............................................................. 1 1.3 参考资 料 ................................................................. 1 2 管 理 ..................................................................... ........ 1 2.1 机
构..................................................................... 1 2. 2 任务..................................................................... 2 2. 3 职责..................................................................... 2 2.4 接口控 制 (2) 2.5 实现..................................................................... 2 2.6 适用的标准、条例和约 定 (3) 2.6.1 指明 (3) 2.6.2 内容................................................................. 3 3 软件配置管理活 动 (4) 3.1 配置标 识 (4) 3.1.1 基线 (4) 3.1.2 代码、文 档 ........................................................... 4 3.2 配置控制 .................................................................
软件配置管理规范.doc
软件配置管理规范1 1．简介 软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。 1.1 目的 本文档指导项目开展配置管理活动。 1.2 范围 本文档适用于SWL开发小组批准立项的软件项目。 1.3 文档结构 第一部分： 简介，包括本规范的目的、范围、词汇以及所涉及到的参考信息。 第二部分： 配置管理工作规范的正文，包括活动的流程图、进入能及退出的准则、所涉及的角色、相 关活动的阐述、验证与确认能及度量。 第三部分： 变更控制工作规范的正文，包括活动的流程图、进入能及退
出准则、所涉及的角色、相关 活动的阐述、验证与确认能及度量。 第四部分： 参考文献，列出了编写本规范所参考的相关的文献资料。 第五部分： 附录，本文中流程图的标准符号定义。 1.4 词汇表 CM (Configuration Management) 配置管理。 CCB (Change Control Board) 变更控制委员会。 CI (Configuration Item) 配置项，包含文档、程序。 CR (Change Request) 变更请求，对提出的要变更工件或流程的任何请求的统称。在变更请求中记录的信息 是有关当前问题、提议解决方案及其成本的起源和影响的信息。
PCA (Physical Configuration Audit) 物理审计，在配置管理系统中建成立基线的工件是否为“正确”版本。 FCA (Functional Configuration Audit) 功能审计，核心软件配置项的实际性能是否符合它的需求。 基线(Baseline) 己通过复审和批准的工件发布版，由此构成进一步演进或开发的公认基础，并且只能 通过正式程序，例如变更管理和配置控制才能进行更改。 CML (Configuration Management Library) 配置客理库，存储项目工件的所有版本，即存储项目的定义的配置项。 版本(Version) 某个工件的变体，工件的后期版本一般是在初期版本的基础上进行的扩展。 1.5参考信息 1.5.1 可追溯性 CMU/ SET-93-TR-024 Capability Maturity Model SM for Software, Version 1.1
软件项目配置管理计划
中国广东核电集团 CHINA GUANGDONG NUCLEAR POWER GROUP 记录文件 项目编号 项目名称 CGN-IT-C3-A12-01 软件项目配置管理计划 版本编写审核审定批准生效时间A/0 注：如无受控文件标识（蓝色印章）则为非有效版本，以受控文件规定为准。 此文件属中国广东核电集团有限公司所有，未经许可，不得以任何方式外传。
修改记录页
目录 (一)基本信息错误!未定义书签。 (二)角色与职责错误!未定义书签。 (三)配置管理资源错误!未定义书签。 (四)权限分配错误!未定义书签。 (五)配置项计划错误!未定义书签。 (六)配置库基线错误!未定义书签。 (七)配置库备份计划错误!未定义书签。 (八)配置库状态报告错误!未定义书签。 (九)配置审核错误!未定义书签。 (十)审批意见错误!未定义书签。
配置管理计划 基本信息 项目名称： 项目代号： 立项时间： 预计主要项目阶段有： 配置项目命名规则依据： 角色与职责 配置管理资源 本项目使用配置管理工具对各配置项进行存储、版本管理，并提供更新、检索和历史版本的恢复。 提示： （1）配置管理员确定本项目的配置管理软件。例如采用Microsoft公司的TFS或者IBM公司的clearecase。
（2）配置管理员根据所采用的配置管理软件，确定计算机资源（考虑内存、外存、CPU等）。 预计建库申请日期： 预计建库日期： 预计工作库需空间： 权限分配 项目成员访问配置库的ID及PASSWORD默认设置为与域帐号的设置相同。 若个人要求另行设置的，由项目组配置管理员负责汇总后，提交给高级配置管理员调整设置。
软件配置管理计划示例
软件配置管理计划示例 作者：赵文锋计划名CADCSC软件配置管理计划 项目名中国控制系统CAD工程化软件系统 项目委托单位 代表签名年月日 项目承办单位 代表签名年月日 1 引言 1．1 目的 本计划的目的在于对所开发的CADCSC软件规定各种必要的配置管理条款，以保证所交付的CADCSC软件能够满足项目委托书中规定的各种原则需求，能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。 软件开发单位在开发本项目所属的各子系统（其中包括为本项目研制或选用的各种支持软件）时，都应该执行本计划中的有关规定，但可以根据各自的情况对本计划作适当的剪裁，以满足特定的配置管理需求。剪裁后的计划必须经总体组批准。 1．2 定义 本计划中用到的一些术语的定义按GB/T 11457 和GB/T 12504。 1．3 参考资料 ◆GB/T 11457 软件工程术语 ◆GB 8566 计算机软件开发规范 ◆GB 8567 计算机软件产品开发文件编制指南 ◆GB/T 12504 计算机软件质量保证计划规范 ◆GB/T 12505 计算机软件配置管理计划规范 ◆CADCSC 软件质量保证计划 2 管理
2．1 机构 在本软件系统整个开发期间，必须成立软件配置管理小组负责配置管理工作。软件配置管理小组属项目总体组领导，由总体组代表、软件工程小组代表、项目的专职配置管理人员、项目的专职质量保证人员以及各个子系统软件配置管理人员等方面的人员组成，由总体组代表任组长。各子系统的软件配置管理人员在业务上受软件配置管理小组领导，在行政上受子系统负责人领导。软件配置管理小组和软件配置管理人员必须检查和督促本计划的实施。各子系统的软件配置管理人员有权直接向软件配置管理小组报告子项目的软件配置管理情况。各子系统的软件配置管理人员应该根据对子项目的具体要求，制订必要的规程和规定，以确保完全遵守本计划规定的所有要求。 2．2 任务 在软件工程化生产的各个阶段中，与本阶段的阶段产品有关的全部信息在软件开发库存放，与前面各个阶段的阶段产品有关的信息则在软件受控库存放。在研制与开发阶段的阶段产品的过程中，开发者和开发小组长有权对本阶段的阶段产品作必要的修改；但是如果开发者或开发小组长认为有必要个性前面有关阶段的阶段产品时，就必须通过项目的配置管理小组办理正规的审批手续。因此，软件开发库属开发这个阶段产品的开发者管理，而软件受控库由项目的配置管理小组管理。软件经过组装与系统测试后，应该送入软件产品库，如欲对其修改，必须经软件配置管理小组研究同意，然后报项目总体组组长批准。关于软件配置要进行修改时的具体审批手续，将在第条中详细规定。 2．3 职责 在软件配置管理小组中，各类人员要互相配合、分工协作，共同担负起整个项目的软件配置管理工作。其中各类人员的分工如下： A．组长是总体组代表，他对有关软件配置管理的各项工作全面负责，特别要对更改建议的审批和评审负责； B．软件工程小组组长负责监督在软件配置管理工作中认真执行软件工程规范； C．项目的专职配置管理人员检查在作配置更改时的质量保证措施； D．各子系统的配置管理人员具体负责实施各自的配置管理工作，并参与各子系统的功能配置检查和物理配置检查；
配置管理岗位职责
配置管理员岗位职责 摘自：软件配置管理论坛 一、配置经理的基本技能与资格 资格： 能够重视配置管理工作； 能够按规范实施配置管理工作； 积极支持部门的配置管理方面的工作； 能够积极支持与帮助其他人员； 为部门的配置管理能力的提高贡献力量； 熟悉公司配置流程以及其他相关的流程； 为增进项目管理，对于项目内的困难和关键问题，能够及时反映到部门； 基本技能： 能够独立规划项目的配置管理工作； 熟练掌握配置管理的相关概念； 能够了解配置的相关工具，熟练使用技术工程部配置所使用的工具； 具有基本的与人沟通的技巧； 能够了解项目管理过程中的主要环节； 初步了解项目管理过程中的质量保证的各个方面； 了解部分系统和应用工具，如数据库ORACLE，前台开发工具DEPHI等； 二、配置经理的职责 作为一名配置人员，配置经理的职责就是能够与质量人员、测试人员等共同保证项目的质量。如：作为质量保证的成员之一，能够为整个技术工程部规范化管理的推进作贡献，如宣传规范化管理的知识，陈述规范化管理的利弊等；能够在项目进行的整个生命过程中，不断的与项目经理、QA、SCCB及项目成员进行配置管理规范化的沟通，为项目配置管理的规范化作出努力. 具体表现为： ?项目进行初期或首次进入项目中时，能够首先与项目经理、QA、SCCB及项目成员就项目的未来配置管理工作进行沟通，取得项目经理、QA、SCCB及项目全体成员对配置工作的认可与支持； ?积极了解项目情况，项目各阶段的进展，为更好的进行配置管理作努力； ?熟练并充分的利用配置管理工具的各方面的功能，提高配置管理的效率； ?为项目控制好版本，保证项目各阶段所使用的版本正确； ?及时发现项目问题，把问题及时反馈给项目经理、QA或SCCB，并积极协助解决； ?与项目内其他组成员，如开发组、测试组等协调工作，并能够很好的沟通； ?能够在项目中不断总结、分析，为项目内配置管理工作的进一步优化作贡献；
软件配置管理规范流程模板
软件配置管理规范 流程 1 概述 1.1 目的 本文档主要目的在于规范项目配置管理活动, 确保配置项正确地唯一标识而且易于存取, 保证基线配置项的更改受控, 明确基线状态, 在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用范围本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动, 针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法, 本文件以CVS( 并行版本系统) 配置管理工具为例, 规定公司的配置管理办法, 使用其它工具时也可对应本文件
的要求参照执行。 1.3 术语和缩略语 1.3.1 软件配置管理( Software Configuration Management, SCM) 软件配置管理是对软件修改进行标识、组织和控制的技术, 用来协调和控制整个过程。是经过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程, 确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 1.3.2 配置项( Configuration Item, CI) 凡是纳入配置管理范畴的工 作成果统称为配置项, 配置项逻辑上组成软件系统的各组成部分, 一般是能够单独进行设计、实施和测试的。 每个配置项的主要属性有: 名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里, 确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 1.3.3 基线( Baseline) 在配置管理系统中, 基线就是一个配置项或一组配置项在其生命周期的不同时间点上经过正式评审而进入正式受控的一种状态这些配置项构成了一个相对稳定的逻辑实体, 而这个过程被称为基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素( 配置项) 的一个版本, 且只确定一个版本。一般情况下, 基线一般在指定的里程碑处创立, 并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制, 基线中的配置项被冻结”了, 不能再
软件项目配置管理系统计划清单指导应用清单
中国核电集团 CHINA GUANGDONG NUCLEAR POWER GROUP 记录文件 项目编号 项目名称 CGN-IT-C3-A12-01 软件项目配置管理计划 版本编写审核审定批准生效时间A/0 注：如无受控文件标识（蓝色印章）则为非有效版本，以受控文件规定为准。 此文件属中国核电集团所有，未经许可，不得以任何方式外传。
修改记录页
目录 (一)基本信息 (4) (二)角色与职责 (4) (三)配置管理资源 (5) (四)权限分配 (5) (五)配置项计划 (6) (六)配置库基线 (7) (七)配置库备份计划 (8) (八)配置库状态报告 (8) (九)配置审核 (9) (十)审批意见 (9)
配置管理计划(一)基本信息 项目名称： 项目代号： 立项时间： 预计主要项目阶段有： 配置项目命名规则依据： (二)角色与职责
(三)配置管理资源 本项目使用配置管理工具对各配置项进行存储、版本管理，并提供更新、检索和历史版本的恢复。 提示： （1）配置管理员确定本项目的配置管理软件。例如采用Microsoft公司的TFS或者IBM公司的clearecase。 （2）配置管理员根据所采用的配置管理软件，确定计算机资源（考虑存、外存、CPU等）。 预计建库申请日期： 预计建库日期： 预计工作库需空间： (四)权限分配 项目成员访问配置库的ID及PASSWORD默认设置为与域的设置相同。 若个人要求另行设置的，由项目组配置管理员负责汇总后，提交给高级配置管理员调整设置。
(五)配置项计划 填写上面表格过程中，需要对照成果物列表逐项填写。
研发项目管理之配置管理规程
研发项目管理之配置管理规程 1 总则 1.1概述 在项目整个生命周期中项目管理员应对研发工作产品进行标识，跟踪完成有关基线变更处理。 1.2基本原则 项目配置管理的目的是建立和维护项目在整个生命周期产品的统一性、完整性和可追溯性。应遵循的原则： 项目管理员负责项目配置管理。 项目配置管理工作贯穿项目的整个生命周期。 项目管理员应定期检查配置管理工作。 项目结项时应提交配置状态记录表。 1.3人员要求及岗位职责 1.3.1项目管理员 1.3.1.1职责 建立基线库，实施版本控制；收到或更改某个配置项时，应及时通知有关人员；记录并维护配置状态信息，配合项目管理员及领导对项目配置管理的定期检查工作。项目结项时，应对项目的配置情况进行总结，最终提交配置状态记录表并存档。 1.3.1.2岗位要求 接受相关配置管理规范、变更管理规程的培训。
1.3.2项目经理、开发部经理 1.3. 2.1职责 定期或在事件驱动下检查配置管理工作。 1.3. 2.2岗位要求 接受相关配置管理规范、变更管理规程的培训。 1.4资源保证 公司研发部门保证提供完成项目配置管理工作所需的资源、工具和人力。 2 规范流程 2.1.1配置管理规范 2.1.1.1目的 指导项目管理员进行配置管理工作。 2.1.1.2适用范围 公司研发部门所有开发项目 2.1.1.3配置管理过程 2.1.1. 3.1制定配置管理计划 项目管理员负责制定项目配置管理计划，内容包括项目中将要进行的配置管理活动、时间安排、相关资源，职责分配等。 对于配置项变更应按照“变更请求流程”来进行。 配置管理计划应经项目经理审核 配置管理计划由项目管理员负责管理和控制，由项目组遵照实施。
软件配置管理计划模板
卷号DEPLOY 卷内编号DEPLOY005 密级组内 HD20090917SR005 通用型行政审批服务协同管理平台 配置管理计划 1.2 项目承担部门：java第四组 撰写人（签名）：区允文 完成日期：2010年8月4日 本文档使用部门：■主管领导■项目组 □客户（市场）□维护人员□用户 评审负责人（签名）：江威龙 评审日期：2010/8/4
目录 1.简介4 1.1目的4 1.2范围4 1.3定义、首字母缩写词和缩略语4 1.4参考资料4 1.5概述4 2.项目配置4 2.1组织结构4 2.2职责和接口5 2.3工具、环境和基础设施5 3.配置管理活动6
3.1配置库6 3.1.1配置库架构6 3.1.2权限分配7 3.1.3配置库层次及开发活动说明：8 3.2配置标识9 3.2.1标识方法9 3.2.2项目基线10 3.3配置项11 3.4配置和变更控制11 3.4.1变更请求的处理和审批11 3.4.2变更控制委员会 (CCB)11 3.4.3变更过程中的活动11 3.4.4变更过程中的变更请求状态12 3.4.5保存变更历史记录13 3.4.6变更请求中受影响配置项的变更13 3.5配置状态统计14 3.5.1项目介质存储和发布进程14 3.5.2报告和审计14 4.里程碑15 5.培训和资源15 6.分包商和厂商软件控制15 7.附录15
配置管理计划 1.简介 1.1目的 为了使项目相关的各种资源便于查看，修改，不至于凌乱；为了让各个开发人员方便高效地协同合作；为了项目的版本便于管理，作出此配置管理计划。 1.2范围 项目进行中所得出的所有工件都要遵守此计划，包括文档以及源代码，以及硬件。 1.3定义、首字母缩写词和缩略语 CM：配置管理。 CCB：变更控制委员会。 CI：配置项。包含文档、程序。 Baseline：基线。 CR：变更请求。 PCA：物理审计。 FCA：功能审计。 1.4参考资料 《华南农业大学软件学院实训讲义》 《华南农业大学项目阶段评审工件》 1.5概述 此文档对项目开发过程中的配置方面作出约束，开发以及变更都要按照要求来做。 2.项目配置 2.1组织结构
软件配置管理规范流程
1 概述 1.1 目的 本文档主要目的在于规范项目配置管理活动，确保配置项正确地唯一标识并且易于存取，保证基线配置项的更改受控，明确基线状态，在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用范围 本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动，针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法，本文件以CVS（并行版本系统）配置管理工具为例，规定公司的配置管理办法，使用其他工具时也可对应本文件的要求参照执行。 1.3 术语和缩略语 1.3.1 软件配置管理（Software Configuration Management，SCM） 软件配置管理是对软件修改进行标识、组织和控制的技术，用来协调和控制整个过程。是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 1.3.2 配置项（Configuration Item，CI） 凡是纳入配置管理范畴的工作成果统称为配置项，配置项逻辑上组成软件系统的各组成部分，一般是可以单独进行设计、实施和测试的。 每个配置项的主要属性有：名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 1.3.3 基线（Baseline） 在配置管理系统中，基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，这些配置项构成了一个相对稳定的逻辑实体，而这个过程被称为“基线化”。每一
软件配置管理计划
您现在的位置：需求工程多媒体教学系统>> 教学资料>> 正文 软件项目配置管理范例. 一. 概述 1.1 目的和范围 本文档描述NewSkyCRM软件开发项目的软件配置管理计划，该计划向NewSkyCRM软件开发项目组以及相关受SCM活动影响的组和个人提供相应的说明和活动指南，使某某软件开发中心SCM方针能够在NewSkyCRM软件开发项目的SCM活动中得到贯彻。 本计划适用于NewSkyCRM软件开发项目的整个生命周期。 1.2 软件配置管理计划维护 本计划由NewSkyCRM项目经理和软件配置管理经理共同制订。如果计划中的SCM活动在实施中出现偏离，由软件配置管理经理按照《变更控制规程》及时维护。 1.3 参考资料 《电信NewSkyCRM产品软件开发计划书》，Version 1.3.0， NS.TEL-NewSkyCRM-CRM-RM-03； 《电信NewSkyCRM产品系统功能说明书》，Version 1.1.1， NS.TEL-NewSkyCRM-CRM-RM-02； 某某软件开发中心《软件配置管理过程》，Version 1.1，NS-PROC-SCM-001； 某某软件开发中心《软件配置管理计划规程》，Version 1.0， NS-PROC-SCM-002。 二. 角色与职责 2.1 软件配置管理代表
软件配置管理代表的职责是遵循某某软件开发中心《软件配置管理过程》及有关规程等文档进行软件配置管理活动。 表1软件配置人员表 2.2 配置控制委员会 NewSkyCRM软件开发项目配置控制委员会的职责是管理本项目内软件基线 的变更等操作和配置项/单元标识的审定。主席主持配置控制委员会的活动。 表2配置控制委员会 2.3 项目经理 NewSkyCRM软件项目经理必须履行某某软件开发中心《软件配置管理过程》及有关规程等文档中指定的有关项目经理的职责。 2.4 项目开发组 NewSkyCRM软件项目开发组必须履行某某软件开发中心《软件配置管理过程》及有关规程等文档中指定的有关项目开发组的职责。 表3项目组成员表
配置管理规范文件精选
配置管理规范
配置管理规范模板 目录 1. 目的 2. 适用范围 3. 术语和缩略语 4. 规范内容 5. 引用文件 1. 目的 指导配置管理人员如何建立配置库，并利用配置库管理所有配置项，从而提供配置项的存取和检索功能，有利于配置项的更改控制，保证配置项的完整性和可跟踪性。 2. 适用范围 适用于所有软件产品和软件项目的配置项管理。配置管理可采用各种工具及手工办法，本文件以Source safe配置管理工具为例，规定公司的配置管理办法，使用其他工具时也可对应本文件的要求参照执行。 3. 术语和缩略语 本文件采用NP601100《配置管理》程序使用的术语和缩略语的定义。 4. 规范内容 4.1 配置管理的范围 软件配置可包括以下几方面：项目文档，源代码，执行程序，相关设备及资料等。 1）项目文档主要指：立项建议报告、项目启动计划、可行性分析报告、开发计划、需求分析报告、软件功能规格说明书、系统设计报告、数据库表结构、技术报告、总结报告、验收报告以及上述文档的评审记录。 2）相关设备主要指项目开发和运行环境（包括硬件和软件），以及项目开发和测试过程中使用的专用仪器设备，如读卡机、扫描仪等。 3）相关资料主要指客户提供的行业法规，标准及其调研期间提供的业务单据，往来会议记要，传真，电子邮件，重要的电话记录等。 4.2 各配置项的获得 项目立项之后，软件配置管理负责人SCML即可建立项目配置库，并着手收集各配置项。1）项目文档。开发各阶段结束时，软件配置管理负责人SCML可向开发人员索要相关文档及对应评审记录，归到配置库。 2）开发人员在出差前应带好与客户会谈的准备材料。根据出差的任务不同，还应准备客满意度调查表，交付书，验收报告等。返回之前应和客户确认，并在出差回来时交给软件配置管理负责人SCML一份备份，如有客户提供的文献资料、有关设备仪器须进行登记。对于任何正在进行的项目，如有客户来访须做好会议纪要。 3）开发部门发给客户的传真件或客户发来传真至少应在项目档案中保存一份备份。 4）对于源代码和执行程序的管理最好使用工具，条件不具备时，要注意对配置库的目录分配。各开发人员分别建立自己的工作目录，完成后的模块再放到项目相关目录下。 5）在项目结束归档时电子邮件也应作为项目的相关资料进行归档。 4.3 配置库的建立 所有项目应建立一配置库，以便管理前面提到的各配置项。一般的可视化开发环境都有自带的配置管理工具，可以用管理工具来建立配置库，也可以在机器的某目录下建立配置库，手工管理。下面以Source Safe为例描述配置管理库的建立及各配置项的控制方法。各项目在开始时，均应建立以下几项子项目，进行分阶段管理。
软件配置管理计划(SCMP)
软件配置管理计划(SCMP) 说明 《软件配置管理计划》(SCMP)说明在项目中如何实现配置管理。 软件配置管理计划的正本格式如下： 1引言 本章应分成以下几条。 1.1标识 本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号、发行号。 1.2系统概述 本条应简述本文档适用的系统和软件的用途。它应描述系统与软件的一般性质；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；并列出其他有关文档。 1.3文档概述 本条应概括本文档的用途与内容，并描述与其使用有关的保密性与私密性要求。 1.4组织和职责 描述软件配置管理(SCM)负责人和软件配置控制委员会(SCCB)的组成以及他们在项目中的职责和权限；说明与项目配置管理相关的人员，如项目经理、部门SCM组长的职责；描述以上人员之间的关系。 为了能够清晰的表述，可选用图表的方式进行说明。 1.5资源 描述项目配置管理活动所需的各种资源，包括人员、培训、工具、设备、设施等等。其中人员是指人力成本，它是根据项目开发计划中的总工时计算得出的。 2引用文件 本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。本章还应标识不能通过正常的供货渠道获得的所有文档的来源。 3管理 描述负责软件配置管理的机构、任务、职责及其有关的接口控制。 3.1机构 描述在各阶段中负责软件配置管理的机构。描述的内容如下： a.描述在软件生存周期各阶段中软件配置管理的功能和负责软件配置管理的机构； b.说明项目和子项目与其他有关项目之间的关系； c.指出在软件生存周期各阶段中的软件开发或维护机构与配置控制委员会的相互关系。 3.2任务 描述在软件生存周期各阶段中的配置管理任务以及要进行的评审和检查工作，并指出各个阶段的阶段产品应存放在哪一类软件库中(软件开发库、软件受控库或软件产品库)。 3.3职责 描述与软件配置管理有关的各类机构或成员的职责，并指出这些机构或成员相互之间的关系： a.指出负责各项软件配置管理任务(如配置标识、配置控制、配置状态记录以及配置的评审与检查)的机构的职责； b.指出上述机构与软件质量保证机构、软件开发单位、项目承办单位、项目委托单位以及用户等机构的关系； c.说明由本计划第3.2条指明的生存周期各阶段的评审、检查和审批过程中的用户职
软件配置管理工具+Vss+60实用指南
软件配置管理工具Vss6.0实用指南 一、版本管理的必要性 如果说70年代的软件危机导致了软件工程思想的诞生和理论体系的发展，那么80～90年代尤其是90年代软件产业的迅猛发展导致了另一种新思想的产生和实现，这就是软件的版本管理。 只要参加过软件开发的人都清楚，现在的软件项目完全由一个人来完成是难以想象而且也是不可能的，通常是有一个研发小组来共同分析、设计、编码和维护，并有专门的测试小组对已完成编码调试的软件进行全面的测试。在软件开发这个庞大而复杂的过程中，需要涉及到各个方面的人员，信息的交流反馈不仅仅是在研发小组的成员之间及各个研发小组之间，还存在于客户和研发者之间。所有的这些交流反馈意见信息都有可能导致对软件的修改，小的可能只是对某个源文件中的某个变量的定义改动，大到重新设计程序模块甚至可能是整个需求分析变动。在这个工程中，由于软件开发所固有的特征，可能会形成众多的软件版本，而且我们并不能保证不出现错误的修改，而这样的一个困难局面却又非常现实地摆在项目开发管理者的面前，他/她该如何有效地解决这些问题，具体地说就是如下一些问题： 1.怎样对研发项目进行整体管理； 2.项目开发小组的成员之间如何以一种有效的机制进行协调； 3.如何进行对小组成员各自承担的子项目的统一管理； 4.如何对研发小组各成员所作的修改进行统一汇总； 5.如何保留修改的轨迹，以便撤销错误的改动； 6.对在研发过程中形成的软件的各个版本如何进行标识，管理及差异识辨等等。 一个非常直接的反应，我们必须要引进一种管理机制，一个版本管理机制，而且是广义上的版本管理，它不仅需要对源代码的版本进行管理，而且还要对整个项目进行管理。以往的那种被誉为具有良好编程风格的做法，诸如在对他人的源程序进行修改时注释修改原因，修改人和日期，如果是多个成员同时进行了修改，那么需要进行及时的人工的差异比较和综合以便形成一个统一的新版本。这种做法在当前的大型软件的开发中已经越来越没有空间了，可以说是一种以小作坊的形式来面对软件的社会化大生产，再也不可能行得通了。 其实，版本管理的思想很早就存在于软件开发者的头脑之中，只是以往的认识没有现在人们所意识到的那样迫切。UNIX 的程序开发系统较早就提供了能够进行开发小组中源代码版本管理的工具，现在的Linux更是提供功能强大的能够跨平台的版本管理器，国外公司的基于Windows的版本管理器也已经有了比较成熟的产品，国内的研究单位如北京大学计算机系CASE实验室也在致力于这方面的工作。在众多的成熟产品和试验产品中，这里只将对使用比较广泛，有较大用户前景且又能较易获得的版本管理器产品Microsoft公司的Visual SourceSafe6.0进行详细的介绍，针对普通的研发小组的解决方案，及具体的实现。 二、Visual SourceSafe6.0(VSS6.0)简介 VSS6.0现在是作为Microsoft Visual Studio6.0这个开发产品家族的一员，如Visual C++6.0和Visual J++6.0一样。 1.VSS的简单工作原理 Microsoft的VSS6.0解决了软件开发小组长期所面临的版本管理问题，它可能有效地帮助项目开发组的负责人对项目程序进行管理，将所有的项目源文件（包括各种文件类型）以特有的方式存入数据库。开发组的成员不能对该数据库中的
软件配置管理规范
软件配置管理规范1.简介 软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。 目的 本文档指导项目开展配置管理活动。 范围 本文档适用于SWL开发小组批准立项的软件项目。 文档结构 第一部分： 简介，包括本规范的目的、范围、词汇以及所涉及到的参考信 息。 第二部分： 配置管理工作规范的正文，包括活动的流程图、进入能及退出 的准则、所涉及的角色、相关活动的阐述、验证与确认能及度 量。 第三部分： 变更控制工作规范的正文，包括活动的流程图、进入能及退出 准则、所涉及的角色、相关活动的阐述、验证与确认能及度量。 第四部分： 参考文献，列出了编写本规范所参考的相关的文献资料。 第五部分：
附录，本文中流程图的标准符号定义。 词汇表 CM (Configuration Management) 配置管理。 CCB (Change Control Board) 变更控制委员会。 CI (Configuration Item) 配置项，包含文档、程序。 CR (Change Request) 变更请求，对提出的要变更工件或流程的任何请求的统称。 在变更请求中记录的信息是有关当前问题、提议解决方案及 其成本的起源和影响的信息。 PCA (Physical Configuration Audit) 物理审计，在配置管理系统中建成立基线的工件是否为“正 确”版本。 FCA (Functional Configuration Audit) 功能审计，核心软件配置项的实际性能是否符合它的需求。 基线 (Baseline) 己通过复审和批准的工件发布版，由此构成进一步演进或开 发的公认基础，并且只能通过正式程序，例如变更管理和配 置控制才能进行更改。 CML (Configuration Management Library)
配置管理计划V0.1
XXX项目配置管理计划 xxxxxxxxxxxxxxx公司20xx 年xx月xx 日
文档编号：XXXXXXXX-XXX-XXX 版本号：1.00 项目名称:XXXX项目 文档名称: 版本修改内容描述修改人日期备注1.0 第一版xxx 2014.6.3 1.01修正了……xxx 2014.6.3 批准人：日期：审核人：日期： 公司名称：xxxxxxxxxxxxxxxxxx有限公司 地址：xxxxxxxxxxxxxxxxxxxxxxxxx 电话：010-xxxxxxxx 网址：https://www.sodocs.net/doc/744667097.html, 邮箱：mengsuran@https://www.sodocs.net/doc/744667097.html,
目录 1. 引言 (1) 1.1 目的 (1) 1.2 术语定义 (1) 1.2.1软件配置管理 (1) 1.2.2 配置管理 (1) 1.2.3 配置项 (1) 1.2.4 基线 (1) 1.2.5 变更控制 (2) 1.2.6 配置审计 (2) 1.3 参考资料 (2) 2. 软件配置 (3) 2.1 软件配置环境 (3) 2.1.1服务器软件环境 (3) 2.1.2 硬件环境 (3) 2.1.3 配置管理客户端 (3) 2.2 软件配置项 (3) 2.2.1 受控配置项 (3) 2.2.2 非受控配置项 (4) 2.3 配置管理员 (4) 2.3.1 设立的必要性 (4) 2.3.2 主要职责 (4) 3. 软件配置管理计划 (4) 3.1 建立示例配置库 (4) 3.2 配置标识管理 (6) 3.2.1文档 (6) 3.2.2 程序 (6) 3.2.3 基线 (6) 3.3 配置库控制 (6) 3.3.1 .权限控制 (6) 3.3.2 配置库控制 (6) 3.3.3 建立软件库 (6) 3.3.4软件配置更改 (7) 3.3.5配置文件清单的维护 (7) 3.4 配置的检查和评审 (7) 3.5 配置库的备份 (8) 3.6 配置管理计划的修订 (9) 3.7 配置管理计划附属文档 (9) 4. 里程碑 (10)