软件公司配置管理计划编写规范
软件配置管理规范标准
软件配置管理规范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)某个工件的变体，工件的后期版本一般是在初期版本的基础上进行的扩展。
3 软件配置管理计划(模板)-GJB438C
密级：内部阶段：版次：A产品（外部）型号+产品（中文）名称软件配置管理计划项目编号-RJPZ共10页XXXX公司XXXX年XX月产品（外部）型号+产品（中文）名称软件配置管理计划项目编号-RJPZ编制审核会签批准修改页本文件版本情况如下：目录1范围 (1)1.1标识 (1)1.2系统概述 (1)1.3文档概述 (1)1.4与其他计划之间的关系 (1)2引用文档 (2)3组织和职责 (2)4软件配置管理活动 (2)4.1配置标识 (2)4.1.1源代码配置项标识 (2)4.1.2文档配置项标识 (3)4.1.3软件运行体配置项标识 (3)4.1.4数据配置项标识 (3)4.2配置控制 (3)4.2.1软件三库的控制 (3)4.2.2软件更改的控制 (4)4.3配置状态记实 (4)4.4配置审核 (5)4.5软件发行管理和交付 (5)5工具、技术和方法 (5)6对供货单位的控制 (5)7进度表 (6)8注释 (6)1范围1.1标识本文档适用于产品（外部）型号+产品（中文）名称的软件管理，软件的完整标识为XXXX。
1.2系统概述产品（外部）型号+产品（中文）名称的软件分为XXXX。
各部分软件实现的功能如下：a)XXXX软件：XXXX；b)XXXX软件●XXXX；●XXXX；●XXXX。
c)XXXX软件●XXXX；●XXXX；●XXXX；●XXXX。
产品（外部）型号+产品（中文）名称的软件研制过程与产品研制周期保持同步，随产品交付用户。
1.3文档概述本文档规定了XX软件开发过程中的配置管理组织结构、职责及活动要求，软件三库的维护安排，明确了软件开发过程输出版本控制以及变更要求，是实施配置管理活动的依据。
1.4与其他计划之间的关系软件配置管理计划作为《软件开发计划》的一部分，应按照总体开发计划的要求协调，使项目软件开发按照合理规划有条不紊的进行，确保软件配置的有效性、适宜性和可追溯性。
2引用文档下列标准和文件中的有关条款，通过引用而成为本管理计划的条款。
软件配置管理规范范本
软件配置管理规范范本一、引言软件配置管理（Software Configuration Management，简称SCM）是软件工程中的重要环节，致力于有效管理和控制软件系统的构建、测试、发布和变更过程。
本文旨在提供一个软件配置管理规范范本，以帮助软件开发团队建立和执行一套合适的配置管理规则，确保软件项目的顺利进行。
二、配置管理范围1. 配置项范围- 软件源代码及可执行文件- 文档和用户手册- 测试用例和测试数据- 第三方库和组件- 配置文件和参数设置2. 配置管理活动范围- 版本控制：管理和跟踪软件所有配置项的版本变更和发布记录。
- 配置识别：将软件系统划分为不同的基线和模块，并进行唯一标识。
- 变更控制：确保任何软件变更都经过审批，并对变更进行记录和追踪。
- 配置审计：定期对软件配置进行审查，确保与规范一致。
- 配置状态管理：记录和跟踪软件配置的当前状态，包括开发、测试和生产。
- 工具支持：选择和使用适当的配置管理工具，提高效率和可追溯性。
三、配置管理规范1. 配置识别- 为每个配置项分配唯一的标识符，以便于跟踪和引用。
- 对软件系统进行模块化划分，每个模块应有清晰的功能和职责范围。
- 为每个配置项编写适当的描述和说明文档，包括用途、版本和所属模块等信息。
2. 版本控制- 使用版本控制工具对所有配置项进行管理，确保源代码、文档和其他资源都有清晰的版本历史。
- 维护一个主干（trunk）和分支（branch）的代码库，确保主干代码是稳定且可用的，分支用于并行开发和修复bug。
- 每个版本的发布都应有相应的发布说明，描述变更内容和风险评估。
3. 变更控制- 所有变更都必须通过变更管理流程进行审批和追踪，包括新功能添加、缺陷修复和配置项删除。
- 每个变更都要有详细的变更请求和变更记录，包括变更的原因、影响分析和验证计划等。
- 变更影响评估必须在变更实施之前进行，确保变更不会导致质量问题或功能冲突。
软件项目配置管理规范(配置项标识和配置审计的标准)
软件项目配置管理规范（配置项标识和配置审计的标准）1．概述本规范用于规范和指导全公司的配置管理活动，适用公司研发项目及技术支持阶段产品的开发工作，主要包括以下几个方面：建立和维护配置管理环境。
公司配置库权限管理配置库的备份和恢复。
公司配置管理相关规程及工具的培训。
制定和维护基线计划。
标识配置项。
变更控制和管理。
版本管理。
配置审计。
2．术语及定义配置管理（Configuration Management，CM）：是一套应用技术上和管理上的指导和监督的方法，用来识别和记录配置项和功能特征和物理特征；控制这些特征的变更；记录和报告变更的处理和执行的状态；以及验证其是否符合特定的需求（IEEE-STD-610）。
配置项（Configuration Item，CI）：配置管理中可相对独立地进行管理的单元，如文档和模块代码。
基线（Baseline）：经过正式评审并且达成一致的一组工作产品，是进一步工作的稳定基础；基线化后的工作产品只能依据变更控制规程通过变更评估、审批后才能变更。
配置审计（Configuration Audit，CA）：通过对配置库进行物理审计和功能审计来验证配置项信息与配置标识的一致性，确保软件资产备份的有效性和完整性。
配置库备份：配置库的备份包括全量备份和增量备份。
3．配置项标识编写《配置项识别表》时，配置管理工程师负责标识配置项范围，并由项目负责人确认。
项目组成员创立配置项时，根据配置项命名规则分配唯一的标识符，配置项命名根据以下原则。
文档类命名规则：公司级命名规则： [ 简称-] 文档名称 [-模块/主题简称]文档类命名原则：【局点+RM单号】-【项目名】-【文档名称】（如项目规模较大时，需分模块说明时，可增加模块简称的后缀）。
会议纪要等可增加主题简称、日期等后缀。
版本编号规则：v1.0.0.0（m.n.j.k） m 主版本号、n代表次版本号 j代表文档批准次数或者代码发布次数 k文档修改次数或者代码测试次数.配置项状态配置项状态通常有如下三种情况：草稿（draft）;评审中（in review）；已发布（released/passed）日常工作中经常将其剪裁为：草稿（draft）；已发布（released）这两种状态，根据是否通过评审为判断节点。
软件配置管理计划模板
XXXX软件项目配置管理计划XXXX企业有限公司____年___月___日文档信息修改记录目录软件项目配置管理计划 (2)1 引言 (2)1.1 编写目的 (2)1.2 术语定义 (2)1.3 参考资料 (2)2 计划内容 (2)2.1 人员及职责 (2)2.2 软硬件环境计划 (4)2.2.1 项目计划环境 (4)2.2.2 需求分析和设计环境 (4)2.2.3 开发环境 (4)2.2.4 测试环境 (4)2.2.5 配置管理环境 (4)2.3 配置项计划 (4)2.4 配置库计划 (6)2.5 权限计划 (7)2.6 基线计划 (8)2.7 发布计划 (8)2.8 配置库备份计划 (9)软件项目配置管理计划1 引言1.1 编写目的本文档目的在于对本公司项目进行软件配置管理，提高软件质量，降低软件开发成本。
本计划制定了本公司如何进行配置管理活动、活动的计划安排、指派的职责和所要求的资源。
对本公司项目实施软件配置管理活动时，需要参照本计划。
1.2 术语定义1、软件配置管理（SCM）：软件配置管理是一门应用技术、管理和监督相结合的学科，通过标识和文档来记录配置项的功能和物理特性，控制这些特性的变更，记录和报告变更的过程和状态，并验证它们与需求是否一致。
2、配置项（CI）：配置项可包括以下几方面：项目(或活动)文档、源代码、可执行代码、度量数据、变更请求(CR)。
项目(或活动)文档即项目(或活动)相关的规范、指南中定义的各个任务的输出和输入；源代码和可执行代码是特殊的文档；度量数据指度量分析定义表中定义的度量以及对应的实际数据。
3、基线（BaseLine）: 用来标识一组配置项的特定版本的集合的标记，以记录工作成果的历史状态，或通过不同的版本组合定义不同特性的工作成果。
1.3 参考资料2 计划内容2.1 人员及职责1、根据《软件项目计划书》中的角色分配，确定CM，CCB（变更控制委员会）成员；2.2 软硬件环境计划2.2.1 项目计划环境软件：MS Office Word、MS Office Excel、MS Office Project2.2.2 需求分析和设计环境软件：MS Office Word、MS Office Visio、Sybase PowerDesigner、Rational Rose2.2.3 开发环境软件：Windows Visual Studio .Net、MyEclipse、JDK、Apache-Tomcat、Apache、Oracle 10g、SQL Server 2003、WebLogic、SQL Server 2005、Websphere2.2.4 测试环境软件：Load Runner2.2.5 配置管理环境1、软件：TortoiseSVN2.3 配置项计划配置管理员标识配置项，标识符的参考格式为：项目编号-配置项类型-配置项序号-配置项版本配置项名称。
软件管理规范
软件管理规范引言概述：软件管理规范是指在软件开发和运维过程中，为了保证软件的质量和安全性，制定的一系列规则和标准。
遵循软件管理规范可以提高软件开发和运维的效率，减少错误和风险。
本文将从需求管理、开发流程、测试流程、发布流程和维护流程五个方面详细阐述软件管理规范的内容。
一、需求管理1.1 确定需求的来源和优先级：明确需求的来源，包括用户需求、市场需求等，根据需求的重要性和紧急程度进行优先级划分。
1.2 编写清晰的需求文档：需求文档应包含详细的功能描述、性能要求、界面设计等，确保开发人员能够准确理解需求。
1.3 确保需求的可追溯性：需求应具有唯一标识符，方便跟踪和变更管理，同时需求变更应经过合理的评审和批准。
二、开发流程2.1 制定开发计划：根据需求和资源情况，制定合理的开发计划，明确开发阶段、任务分配和进度控制。
2.2 遵循编码规范：制定统一的编码规范，包括命名规则、注释要求等，提高代码的可读性和可维护性。
2.3 进行代码审查：定期进行代码审查，发现潜在问题并及时修复，确保代码质量和安全性。
三、测试流程3.1 制定测试计划：根据需求和开发进度，制定全面的测试计划，包括功能测试、性能测试、安全测试等。
3.2 编写详细的测试用例：根据需求和设计文档，编写详细的测试用例，确保测试的全面性和准确性。
3.3 自动化测试：利用自动化测试工具，提高测试效率和准确性，减少人工测试的工作量。
四、发布流程4.1 配置管理：对软件的配置进行管理，包括版本控制、变更管理等，确保发布的软件版本正确和可追溯。
4.2 灰度发布：采用灰度发布的方式，先将软件发布给部分用户进行测试和反馈，再逐步扩大范围，降低发布风险。
4.3 监控和回滚：发布后进行监控，及时发现问题并进行回滚操作，确保用户的正常使用。
五、维护流程5.1 建立用户反馈渠道：建立用户反馈渠道，及时收集用户的问题和建议，进行问题跟踪和解决。
5.2 定期维护和更新：定期对软件进行维护和更新，修复已知问题和漏洞，提供更好的用户体验和安全性。
软件项目配置管理规范(配置项标识和配置审计的标准)
软件项目配置管理规范（配置项标识和配置审计的标准）1．概述本规范用于规范和指导全公司的配置管理活动，适用公司研发项目及技术支持阶段产品的开发工作，主要包括以下几个方面：建立和维护配置管理环境。
公司配置库权限管理配置库的备份和恢复。
公司配置管理相关规程及工具的培训。
制定和维护基线计划。
标识配置项。
变更控制和管理。
版本管理。
配置审计。
2．术语及定义配置管理（Configuration Management，CM）：是一套应用技术上和管理上的指导和监督的方法，用来识别和记录配置项和功能特征和物理特征；控制这些特征的变更；记录和报告变更的处理和执行的状态；以及验证其是否符合特定的需求（IEEE-STD-610）。
配置项（Configuration Item，CI）：配置管理中可相对独立地进行管理的单元，如文档和模块代码。
基线（Baseline）：经过正式评审并且达成一致的一组工作产品，是进一步工作的稳定基础；基线化后的工作产品只能依据变更控制规程通过变更评估、审批后才能变更。
配置审计（Configuration Audit，CA）：通过对配置库进行物理审计和功能审计来验证配置项信息与配置标识的一致性，确保软件资产备份的有效性和完整性。
配置库备份：配置库的备份包括全量备份和增量备份。
3．配置项标识编写《配置项识别表》时，配置管理工程师负责标识配置项范围，并由项目负责人确认。
项目组成员创立配置项时，根据配置项命名规则分配唯一的标识符，配置项命名根据以下原则。
文档类命名规则：公司级命名规则： [ 简称-] 文档名称 [-模块/主题简称]文档类命名原则：【局点+RM单号】-【项目名】-【文档名称】（如项目规模较大时，需分模块说明时，可增加模块简称的后缀）。
会议纪要等可增加主题简称、日期等后缀。
版本编号规则：v1.0.0.0（m.n.j.k） m 主版本号、n代表次版本号 j代表文档批准次数或者代码发布次数 k文档修改次数或者代码测试次数.配置项状态配置项状态通常有如下三种情况：草稿（draft）;评审中（in review）；已发布（released/passed）日常工作中经常将其剪裁为：草稿（draft）；已发布（released）这两种状态，根据是否通过评审为判断节点。
软件配置管理规范流程
1概述目的本文档主要目的在于规范项目配置管理活动,确保配置项正确地唯一标识并且易于存取,保证基线配置项的更改受控,明确基线状态,在整个软件生命周期中建立和维护项目产品的完整性和可追溯性;适用范围本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动,针对项目不同在流程上作适当的删减;配置管理可采用各种工具及手工办法,本文件以CVS并行版本系统配置管理工具为例,规定公司的配置管理办法,使用其他工具时也可对应本文件的要求参照执行;术语和缩略语软件配置管理Software Configuration Management,SCM软件配置管理是对软件修改进行标识、组织和控制的技术,用来协调和控制整个过程;是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施;配置管理的目标是记录软件产品的演化过程,确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置;配置项Configuration Item,CI凡是纳入配置管理范畴的工作成果统称为配置项,配置项逻辑上组成软件系统的各组成部分,一般是可以单独进行设计、实施和测试的;每个配置项的主要属性有：名称、标签、文件状态、版本、作者、日期等;所有配置项都被保存在配置库里,确保不会混淆、丢失;配置项及其历史记录反映了软件的演化过程;基线Baseline在配置管理系统中,基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态,这些配置项构成了一个相对稳定的逻辑实体,而这个过程被称为“基线化”;每一个基线都是其下一步开发的出发点和参考点;基线确定了元素配置项的一个版本,且只确定一个版本;一般情况下,基线一般在指定的里程碑处创建,并与项目中的里程碑保持同步;每个基线都将接受配置管理的严格控制,基线中的配置项被“冻结”了,不能再被任何人随意修改,对其修改要严格地按照变更控制的过程进行;在一个软件开发阶段结束时,上一个基线加上增加和修改的基线内容形成下一个基线;基线的主要属性有：名称、标签、版本、日期等;权限与职责研发总经理助理1 审核变更请求;项目经理Project Manager,PM1 审核批准配置管理计划；2 接收或拒绝小范围的变更申请；3 召集评估变更；4 提出配置管理的建议和要求；5 配合配置管理员的工作;配置管理员Configuration Management Officer,CMO1 编写配置管理计划；2 执行版本控制和变更控制方案；3 制定访问控制策略；4 负责项目的配置管理工作,包括搭建环境、权限分配、配置库的建立、配置项的控制等；5 配置管理工具的日常管理与维护；6 配置库的日常操作和维护；7 负责配置审核并提交报告；8 根据配置部署表单编译发布版本,并维护版本；9 对开发人员进行相关的培训；10 对配置审核中发现的不符合项,拟订纠正措施,要求相关责任人进行纠正;11 监督项目组成员规范的执行情况;开发人员Developer1 根据确定的配置管理计划和相关规定,提交配置项和基线；2 负责项目组内部测试；3 负责软件集成和版本生成；4 按照软件配置管理工具的使用模型来完成开发任务;2 实施细则配置项管理配置项的范围软件配置可包括以下几方面：开发文档,代码,第三方控件、插件,参考资料,测试文档,用户文档,项目管理文档,验收文档等;l 项目文档主要指：立项建议书、可行性分析报告、技术建议书、用户需求说明书、项目计划、项目进度计划、项目阶段性计划、产品需求规格说明书、概要设计报告、详细设计、数据库设计、界面设计、用户操作手册、用户安装手册、培训文档、验收报告以及上述文档的评审记录;l 代码主要指：源代码等;l 工具主要指：脚本文件、插件、第三方控件等;配置项基线管理结合SPP和ISO9000的相关规定,配置管理员根据配置管理规范及配置管理计划,对配置项进行分阶段管理,每一阶段正式评审通过后纳入受控库,作为该项目的一个基线;l 项目启动：配置项包括技术建议书、可行性分析报告、用户需求说明书等立项阶段产生的文档,评审或审批通过后建立发布基线;l 需求阶段：系统调研后开发人员进行需求分析,并整理产品需求规格说明书;产品需求规格说明书经过客户的确认后,建立需求基线;如需升级版本则必须通过评审或审批并得到客户的确认;l 项目计划：需求分析完成后即可制定项目的开发计划,包括项目计划和主要下属计划;包括项目进度计划、配置管理计划、质量保证计划、测试计划、项目阶段性计划;项目开发计划评审通过后,建立项目计划基线;l 设计：系统设计可分为概要设计、详细设计、数据库设计、数据库字典、界面设计;针对用户需求规格说明书进行系统设计,配置时应说明系统设计的版本与需求分析报告版本的对应关系;设计说明书评审或审批通过后,建立设计基线;l 编码设计实现：编码按功能模块分子项目,即每个模块记作一个配置项;代码在提交项目组系统测试时建立Beta版本,系统测试产品正式发布后建立Version版本;l 测试：单元测试和系统测试;单元测试通过提交单元测试报告,项目启动后应提交系统测试计划,系统测试完成后应提交系统测试报告;配置时应说明测试的版本与编码版本的对应关系;系统测试完成后建立测试基线;l 版本发布：项目组提交部署表单,CMO根据部署表单进行编译,发布测试服务器上,并对版本进行维护;同时将发布的版本上传到文档服务器上备份;l 交付与验收：在交付前配置审核完成后建立产品基线,产品基线包含程序以及有关文档配置项,包括交付文档、代码、工具等;l 产品部署：部署时应包括操作手册、安装维护手册、维护文档以及必要的业务和技术培训文档;l 相关资料：相关资料也应作为配置项纳入配置管理,此部分包括：1 相关法律、法规；必须遵照或项目组约定的技术规范；2 与客户或项目组内部重要的交互信息记录,如会议记录、会谈记录、e-mail和MSN 记录等；版本控制文档的版本控制所有文档的管理纳入配置管理库,用版本控制工具进行统一管理;文档的版本控制主要通过文档的名称、文档控制页及版本控制工具的标签来实现,主要分为以下几类：版本变化型文档命名方式：文档名称+子系统名称可选适用文档：项目计划、配置管理计划、质量保证计划、项目进度计划、用户需求规格说明书、产品需求规格说明书、体系结构设计报告、数据库设计报告、详细设计报告、用户操作维护手册、测试用例等;示例：项目计划.doc详细设计_SP门户.doc标签结构：大版本+ 子系统简称+ 版本号+ 日期标签控制说明版本信息l 大版本：可选,表示同一项目为不同用户定制的版本;l 子系统简称：可选,当一个项目有多个子系统时,为区分不同子系统而设置;l 版本号：采用Vs_x_y的形式;l 日期：纳入基线管理的日期,用8位表示,如说明：a. 文档发布名称采用文档名+ Vs_x_y的形式,文档的版本号应该和版本控制工具中相应标签上的版本号一致;b. 对文档的修改需要从配置管理库中取到本地进行;c. 对于文档小的修改,如文字错误,格式调整,变更Vs_x_y中的y来区别如：V1_0_1;d. 文档内容没有大的增加和删节,意思表述没有发生重大的变化,版本标识通过版本工具中加上x标签来表示如：V1_1_0,以及在文档内部控制页标注变化来表示;e. 文档有重大增加和删节,意思表述有重大变化的,版本标识通过在相应文档加上s 标签来表示如：V2_0_0;f. 对于纳入基线库的文档的修改需要提交变更申请,经批准才能进行修改,并且修改的内容要经再次评审才能重新纳入基线库,作为后续阶段的参考文档;时间区别型文档命名方式：文档名称＋撰写时间适用文档：文档名称有明确的含义,需要用时间标识的日常性文档;如周例会会议纪要,项目月计划,项目月总结,阶段性计划等等;示例：周例会会议纪要时间序号型文档命名方式：文档名称+人员姓名拼音+撰写时间+序列号适用文档：测试报告示例：单元测试报告其他文档：对于不能按照前四种类型进行命名的文档会议纪要：会议纪要YYYYMMDD示例：9月9日召开的项目启动会命名为：会议纪要项目启动.doc评审报告：评审报告YYYYMMDD同”会议纪要”要求一致;示例：10月9日召开的项目总体方案评审命名为：评审报告总体方案.doc发行版本表示发行版本采用标签说明,结构如下：大版本+ 版本类型+ 版本号+ 子系统简称拼音+日期+序号大版本：可选,表示同一项目为不同用户定制的版本;子系统简称：可选,当一个项目有多个子系统时,为区分不同子系统而设置;版本类型：分为3种Beta表示项目组内部测试,标签：Release系统测试,标签：Version正式发行版,标签：版本号对于Version正式发行版是必须要注明的,而其它可选;发行产品基线在版本号前加Version,如Version_1, Version_2, Version_3….表示分支；Version_1_0, Version_1_1, Version_1_2… 表示在分支Version_1上的标签；Version_0_0, Version_0_1, Version_0_2… 表示在主线上的标签;配置库管理配置库的分类配置库统一由配置管理员负责管理,服务器端使用,客户端主要使用乌龟CVS;配置库目录结构如下：配置库的建立所有项目应建立配置库,以便管理各配置项,配置管理员组织建立配置库;程序库主要通过设置版本的分支来实现对配置项权限管理：1开发库：开发人员相对比较自由的存储空间,开发人员可以在自己的权限范围内任意取出提交;2基线库：配置管理员有最高权限,其余相关人员均为读的权限,发生变更时变更人员须提交变更申请后方可修改基线库内的配置项;文档评审通过后,文档严格受控;由配置管理员将通过评审后的文档移植到基线库里同时将该配置项从开发库移除;代码一般在移交系统测试时纳入基线库受控,可根据项目的具体情况设置基线;3产品库：产品库的产品均出自于基线库,产品库存储的产品用于交付和存档;配置三库统一由配置管理员管理,根据各开发阶段的实际情况定制相应的版本选取规则,来保证开发活动的正常运作;在变更发生时,应及时做好基线的推进;分配权限项目开始后配置管理员编写配置库目录结构表明确项目组成员以及相关人员的权限;在wincvs里有三种权限,读r、写w、添加删除c权限;在开发库内,文档部分项目组成员有rcw权限,其他相关人员只r权限；代码部分项目组成员有rcw权限,其他相关人员没有任何权限;在基线库内,项目组成员仅有r权限,其他相关人的权限视情况而定;在产品库内,所有人没有任何权限;配置管理员在三库内均拥有最高权限;配置变更控制变更的分类软件及其相关文档的变更按照变更的影响范围进行分类：1A级：变更会影响系统级的需求、外部接口、产品价格或者交付期；这类变更必须经过配置管理委员会审核并有客户批准和确认;2B级：变更会影响配置项间的功能接口、内部功能的设计、组件；这类变更必须由项目经理或配置管理委员会的批准和认可;3 C级：变更只会影响配置项内部或对BUG问题的处理；这类变更可以由配置项的管理人员负责批准;系统测试前变更控制流程：系统测试完毕发布release版本后变更控制流程图2 变更控制流程变更请求的提出a．由技术支撑中心汇集顾客意见,影响到需求变更则填写配置项变更控制报告,并提交给配置管理员;b．配置管理员对申请表是否清晰、明确和完整性进行审查,若发现变更不明确或不完整,应返回申请者;对通过审查的变更申请分配变更ID,以便跟踪和记录变更信息;评估变更a．配置管理员将配置项变更控制报告发送给项目经理或者其他授权人员,由项目经理负责对变更进行评估;b．项目经理对变更进行分解,一般的BUG修正不需要审批直接由项目经理决定是否需要变更;新增功能或对整个项目影响重大的变更必须由研发总助审批通过后方可变更;变更评估文档在完成变更评估后发送给配置管理员;变更实施和确认a．变更被批准后,项目经理提交变更实施进度计划,开发人员开始实施变更,并详细记录变更的内容；质量部对变更的实施进行跟踪;b．对于代码变更,必须进行回归测试,以确保变更没有引入新的Bug;另外与变更相关的文档必须修订,以反映变更;当变更以及测试完成后,进行提交;c．通过测试后,质保人员需对变更进行审核,审核的范围一般涉及以下方面：测试记录；变更请求；配置项的检入及检出；文件的命名；版本的编号;a．审核后,由配置管理员更新到基线库中;配置状态报告目的记录和报告整个软件生命周期演化状态;记录内容配置状态报告记录的内容包括：1 软件和文档的标识；2 目前状态；3 基线演化状态；4 变更状态；5 版本交付信息等;生成报告配置管理报告自第一个基线创建时建立,由配置管理系统生成,及时反映当前配置状态;配置审核类别配置审核分为：1功能配置审核Functional Configuration Audit,FCA：审核软件功能是否与需求一致,并符合基线文档要求,通常要审查测试文档等;2 物理配置审核Physical Configuration Audit,PCA：审核要交付的组成项是否存在,是否包含所有必需的项目,如正确版本的源代码、资源、文档、安装说明等等;执行时机通常选择以下几种情况由质量保证人员负责实施配置审核：1软件产品交付或是软件产品正式发行前；2软件开发的阶段工作结束后；3在产品维护工作中,定期地进行;不符合项处理对配置审核中发现的不符合现象,配置管理员进行记录,并交由责任部门限期进行纠正,配置管理员负责纠正措施的验证;所有的不符合项报告均关闭后,才能发布新版本;发行管理通过配置审核后,经项目经理批准,由配置管理员负责生产新版本;交付管理这里“交付”是指从配置库中提取配置项,交付给客户或项目外的人员;交付出去的配置项必须有据可查,避免发生混乱;流程如下：1交付人向质量部申请；2质量部如果不同意交付,则拒绝交付配置项;如果同意交付,配置管理员应给出详细的交付清单；3交付人验收后签字;。
软件管理规范
软件管理规范引言概述：软件管理规范是指在软件开发、维护和使用过程中，为了保证软件质量和项目进度的规范性，制定的一系列管理规则和标准。
本文将从四个方面详细阐述软件管理规范的重要性和具体内容。
一、需求管理1.1 确定需求：通过与项目相关方的沟通和讨论，明确软件的功能和性能需求，并将其记录下来。
1.2 需求分析：对需求进行详细分析，将其拆解成具体的任务和模块，并制定相应的计划和时间表。
1.3 需求变更管理：及时响应需求变更，并评估其对项目进度和成本的影响，经过合理的评估后再进行变更。
二、项目管理2.1 项目计划：制定详细的项目计划，包括任务分配、时间安排、资源调配等，确保项目按时完成。
2.2 进度控制：监控项目的进度，及时发现并解决进度滞后的问题，确保项目按计划进行。
2.3 风险管理：识别和评估项目中的风险，并制定相应的应对措施，降低风险对项目的影响。
三、质量管理3.1 测试规范：制定测试计划和测试用例，对软件进行全面的功能测试和性能测试，确保软件的质量。
3.2 缺陷管理：对软件中发现的缺陷进行记录和跟踪，及时修复，并对修复后的软件进行验证。
3.3 文档管理：编写详细的软件需求文档、设计文档和用户手册，确保软件的可维护性和可扩展性。
四、配置管理4.1 版本控制：使用版本控制工具对软件进行管理，确保软件的版本控制和变更管理。
4.2 配置管理计划：制定配置管理计划，包括配置项的标识、控制和审计等，确保软件的配置管理规范执行。
4.3 配置项管理：对软件的各个配置项进行管理，包括配置项的定义、标识、变更控制等，确保软件的配置项正确性和一致性。
总结：软件管理规范是保证软件质量和项目进度的重要手段，通过需求管理、项目管理、质量管理和配置管理等方面的规范，能够提高软件开发、维护和使用的效率和质量，降低项目风险。
因此，软件管理规范的制定和执行对于软件项目的成功至关重要。
软件配置管理计划书
软件配置管理计划书2.2职责。
12.3流程。
12.4工具和技术。
23配置标识。
23.1命名约定。
23.2版本标识符号。
23.3基线标识符号。
24配置管理。
34.1配置项。
34.2变更控制。
34.3版本控制。
44.4审查和审核。
45配置审计。
46配置问题解决。
57培训。
58质量保证。
59风险管理。
610附录。
6引言本文档旨在规范软件配置管理计划的编写，以确保项目的顺利进行。
本文档包括了定义和缩写词、参考资料、管理、配置标识、配置管理、配置审计、配置问题解决、培训、质量保证和风险管理等内容。
管理在软件配置管理中，机构和职责的分配十分重要。
本章节将介绍机构、职责、流程、工具和技术等方面的内容，以确保软件配置管理的有效性。
配置标识配置标识是软件配置管理中非常重要的一部分。
本章节将介绍命名约定、版本标识符号、基线标识符号等内容，以确保配置标识的准确性和一致性。
配置管理配置管理是软件配置管理计划的核心内容。
本章节将介绍配置项、变更控制、版本控制、审查和审核等内容，以确保软件配置管理的有效性。
配置审计配置审计是软件配置管理计划中必不可少的一部分。
本章节将介绍配置审计的相关内容，以确保软件配置管理的有效性。
配置问题解决在软件配置管理中，配置问题解决是非常重要的一部分。
本章节将介绍配置问题解决的相关内容，以确保软件配置管理的有效性。
培训培训是软件配置管理计划中必不可少的一部分。
本章节将介绍培训的相关内容，以确保软件配置管理的有效性。
质量保证质量保证是软件配置管理计划中非常重要的一部分。
本章节将介绍质量保证的相关内容，以确保软件配置管理的有效性。
风险管理风险管理是软件配置管理计划中必不可少的一部分。
本章节将介绍风险管理的相关内容，以确保软件配置管理的有效性。
工具、技术和方法在软件配置管理过程中，有许多工具、技术和方法可以帮助组织和管理软件的版本控制、变更控制和问题跟踪。
其中包括版本控制工具、变更管理工具、问题跟踪工具、构建工具、持续集成工具等。
软件配置管理计划（范本）
软件配置管理计划软件配置管理计划本计划的目的在于对所开发的CADCSC软件规定各种必要的配置管理条款，以保证所交付的C ADCSC软件能够满足项目委托书中规定的各种原则需求，能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。
软件开发单位在开发本项目所属的各子系统（其中包括为本项目研制或选用的各种支持软件）时，都应该执行本计划中的有关规定，但可以根据各自的情况对本计划作适当的剪裁，以满足特定的配置管理需求。
剪裁后的计划必须经总体组批准。
1．2定义本计划中用到的一些术语的定义按GB/T11457和GB/T12504。
1．3参考资料GB/T11457软件工程术语GB8566计算机软件开发规范GB8567计算机软件产品开发文件编制指南GB/T12504计算机软件质量保证计划规范GB/T12505计算机软件配置管理计划规范CADC SC软件质量保证计划2管理2．1机构在本软件系统整个开发期间，必须成立软件配置管理小组负责配置管理工作。
软件配置管理小组属项目总体组领导，由总体组代表、软件工程小组代表、项目的专职配置管理人员、项目的专职质量保证人员以及各个子系统软件配置管理人员等方面的人员组成，由总体组代表任组长。
各子系统的软件配置管理人员在业务上受软件配置管理小组领导，在行政上受子系统负责人领导。
软件配置管理小组和软件配置管理人员必须检查和督促本计划的实施。
各子系统的软件配置管理人员有权直接向软件配置管理小组报告子项目的软件配置管理情况。
各子系统的软件配置管理人员应该根据对子项目的具体要求，制订必要的规程和规定，以确保完全遵守本计划规定的所有要求。
2．2任务在软件工程化生产的各个阶段中，与本阶段的阶段产品有关的全部信息在软件开发库存放，与前面各个阶段的阶段产品有关的信息则在软件受控库存放。
某软件公司配置管理计划编写规范
某软件公司配置管理计划编写规范某软件公司配置管理计划编写规范1. 引言配置管理计划是某软件公司在软件开发过程中进行配置管理的指导文件，包括了配置管理的目标、范围、策略、活动和责任等内容。
本文档旨在规范配置管理计划的编写内容和格式，以确保配置管理工作能够高效进行。
2. 文档组织配置管理计划应该包含以下主要部分：2.1 引言：简要描述配置管理计划的目的、范围和背景等信息。
2.2 配置管理目标：明确配置管理的目标和期望的结果，例如提高软件开发的质量、减少变更的风险等。
2.3 配置管理范围：说明配置管理的范围，包括涵盖的软件项目、开发阶段和相关环境等。
2.4 配置管理策略：定义配置管理的策略和原则，例如变更控制、配置标识、配置审查等。
2.5 配置管理活动：详细描述配置管理的具体活动，例如配置项识别、配置项控制、版本管理、配置审查等。
2.6 配置管理工具：介绍使用的配置管理工具和系统，以及其功能和使用方法。
2.7 配置管理责任：明确配置管理的责任和角色，包括配置管理委员会、项目经理、配置管理员等。
2.8 配置管理培训：描述对相关人员进行配置管理培训的计划和内容。
2.9 配置管理审核：规定配置管理的审核计划，以确保配置管理计划的有效性和改进。
2.10 配置管理计划的更新和变更：说明如何更新和变更配置管理计划，并规定相应的程序和流程。
3. 编写规范为确保配置管理计划的一致性和可读性，应遵循以下编写规范：3.1 文档格式：使用公司规定的文档模板，并确保文档格式清晰、整洁、易读。
3.2 语言和术语：使用清晰简洁的语言，并确保术语的准确性和一致性。
3.3 文档编号：为每个配置管理计划分配唯一的编号，并在文档中注明。
3.4 目录和页眉：在文档中包含完整的目录，并在每页的页眉中标明文档标题和页码。
3.5 图表和表格：使用适当的图表和表格来说明配置管理的流程、活动和责任。
3.6 参考资料：在文档末尾列出所有引用的参考资料和文献，确保引用的准确性和可查性。
《软件配置管理规范》实施细则
目录1 目的 (3)2 配置管理工作授权 (3)3 配置管理库结构标准 (3)4 配置项标识与管理 (3)5 工作流程定义 (4)5.1 项目SCM总流程 (4)5.1.1 编制配置管理计划 (4)5.1.2 配置标识 (4)5.1.3 基线变更控制 (4)5.1.4 配置状态统计/ 报告 (4)5.1.5 配置审核 (4)5.1.6 发布(FCA/PCA) (4)5.2 基线生成、归档 (5)5.2.1 流程 (5)5.2.2 规程 (6)5.2.3 单据 (8)5.3 程序测试 (8)5.3.1 流程 (8)5.3.2 规程 (8)5.3.3 单据 (9)5.4 基线变更控制 (9)5.5 配置状态统计/ 报告 (9)5.6 配置审核 (9)5.6.1 流程 (9)5.6.2 规程 (10)5.6.3 单据 (10)5.7 发布管理(下发) (11)5.7.1 流程 (11)5.7.2 规程 (11)5.7.3 单据 (12)6 配置管理保密管理 (13)7 相关/支持性文件 (13)为了加强公司软件配置管理，保证公司版本管理的一致性，配合《软件配置管理规范》的顺利实施，制定本细则。
1. 公司领导贾林是配置管理工作的最高管理者和权限者，享有VM 和TRACKER系统的用户名和密码，能够对所有项目和产品的任一模块进行任意操作，也可以授权给别人。
既是管理者，又是执行者。
2. 配置管理部经理、部门经理是相应职责范围内的管理者、变更审批者，可以在配置管理部成员或者研发经理/组长配合下检查工作、审核，但不是版本管理工作的执行者，没有VM系统的用户名和密码。
3. 配置管理部组员、研发经理/组长是配置管理操作的管理者和执行者，负责本职责范围内的配置管理工作，并配合相关的检查。
4. 编程人员、文档编制、修改人员是版本管理机的使用者，没有管理权限。
5. 其他人员(如测试、市场、售后、工程等)可以根据需要，在配置管理部申请暂时用户和密码，但必须经过相关领导批准。
计算机软件配置管理计划规范GBT12505-90
计算机软件配置管理计划规范GB/T 12505-90 Specification for computer software configuration management plan1．主题内容与适用范围本规范规定了在制订软件配置管理计划时应该遵循的统一的基本要求。
本规范适用于软件特别是重要软件的配置管理计划的制订工作。
对于非重要软件或已开发好的软件，可以采用本规范规定的要求的子集。
2．引用标准GB/T 11457 软件工程术语GB 8566 计算机软件开发规范GB 8567 计算机软件产品开发文件编制指南GB/T 12504 计算机软件质量保证计划规范3．术语下面给出在本规范中用到的一些术语的定义，其它术语的定义按GB/T 11457。
在引用时，特别要注意线(baseline)、配置控制(configuration)、配置控制组(configuration control board)、配置检查(configuration audit)、配置标识(configurationidentification)禾口配置状态记录(configuration statusaccounting) 等术语的定义。
3．1 项目委托单位project entrust organization项目委托单位是指为产品开发提供资金并通常也是 (但有时也未必) 确定产品需求的单位或个人。
3．2 项目承办单位project undertaking organization项目承办单位是指为项目委托单位开发、购置或选用软件产品的单位或个人。
3．3 软件开发单位software development organization 软件开发单位是指直接或间接受项目委托单位委托而直接负责开发软件的单位或个人。
3．4 用户user 用户是指实际全胜软件来完成某项计算、控制或数据处理等任务的单位或个人。
3．5 软件software软件是指计算机程序及其有关的数据和文档，也包括固化了的程序。
配置管理规范
精品文档精心整理XX软件股份有限公司配置管理规范变更履历目录1 概述42 术语定义 (4)3 适用范围 (5)4 阅读对象 (5)5 配置管理计划 (5)5.1 配置管理计划流程图 (6)5.2 配置管理计划流程说明 (6)6 配置管理软硬件资源确定 (7)6.1 配置管理服务器 (7)6.2 配置管理工具 (8)7 配置项/文档管理 (8)7.1 配置项识别 (8)7.2 配置项编写及命名 (9)7.3 配置项入库 (9)8 配置库目录结构规划 (9)9 权限管理 (10)9.1 用户角色定义 (10)9.2 配置库操作定义 (10)9.3 配置库授权控制参考 (11)9.4 注意事项 (11)10 基线管理 (11)10.1 基线计划制定 (11)10.2 基线建立时机 (12)10.3 基线建立流程 (12)10.4 基线命名规范 (13)11 分支合并管理 (13)11.1 分支建立 (14)11.1.1 分支建立时机 (14)11.1.2 分支建立模式 (14)11.2 分支合并 (14)11.2.1 分支合并类型 (14)11.2.2 版本库发布模式 (14)12 代码集成管理 (15)13 发布管理 (16)13.1 正式版本发布 (16)13.2 测试版本发布 (16)13.3 临时版本发布 (17)14 变更管理 (17)14.1 变更控制 (17)14.2 变更流程 (18)14.3 变更结束准则 (19)15 备份/还原管理 (19)16 生效 (19)17 参考及附录 (20)1概述配置管理（CM）的目的是协调软件开发过程、对项目生命周期过程中各种阶段产品的演化和变更进行管理、使混乱（一旦发生，其代价通常都很大）减至最小，从而保证软件工作产品的一致性和完整性。
从变更的意义讲，配置管理要解决变更标识、变更控制以及变更发布的问题。
配置管理是项目质量管理的重要组成部分，在控制由多人参与项目所生成的大量工作产品时，配置管理过程规范化至关重要。
配置管理计划编写指南(438B)
密级：（软件项目名称）配置管理计划标识：版本：页数：拟制：审核：批准：拟制部门：年月日修改文档历史记录：日期版本说明修改人目录1 范围 (2)1.1 标识 (2)1.2 系统概述 (2)1.3 文档概述 (2)1.4 与其他计划之间的关系 (2)2 引用文档 (2)3 组织和职责 (2)4 软件配置管理活动 (3)4.1 配置标识 (3)4.2 配置控制 (5)4.3 配置状态记实 (5)4.4 配置审核 (5)4.5 软件发行管理和交付 (5)5 工具、技术和方法 (6)6 对供货单位的控制 (6)7 进度表 (6)8 注释 (7)1 范围1.1 标识【本条应描述本文档所适用的系统和软件的完整标识，适用时，包括其标识号、名称、缩略名、版本号和发布号。
】示例：a) 已批准的标识号：b) 软件版本号：c) 缩略语：1.2 系统概述【本条应概述本文档所适用的系统和软件的用途。
它还应描述系统与软件的一般特性；概述系统开发、运行和维护历史；标识项目的需方、用户、开发方和保障机构等；标识当前和计划的运行现场；并列出其它有关文档。
】示例：产品用途：软件用途：需方：开发方：运行环境：相关文档：软件开发计划1.3 文档概述【本条应概述本文档的用途和内容，并描述与它的使用有关的保密性方面的要求。
】示例：本文描述在软件系统开发中采用的软件配置管理的方法和步骤。
与软件开发计划协调一致，为软件配置管理活动提供依据。
1.4 与其他计划之间的关系【本条应描述本计划和其他项目管理计划的关系。
】示例：本文档规定软件项目在研制阶段配置管理的计划和进度，与软件开发计划保持一致。
2 引用文档【本章应列出引用文档的编号、名称、编写单位、修订版及日期，还应标识不能通过正常采购活动得到的文档的来源。
】示例：表1 引用文档3 组织和职责【本章应描述软件配置管理机构的组成及各级软件配置管理机构的职责和权限；说明与软件配置管理相关的人员（如项目经理、部门软件配置管理组组长）在软件配置管理中的职责；描述上述人员之间的关系。
软件管理规范
软件管理规范一、引言软件管理规范是为了确保软件开辟、维护和使用的高效性、可靠性和安全性而制定的一系列准则和标准。
本文档旨在为组织内的软件管理人员、开辟人员和用户提供明确的指导，以确保软件项目的顺利进行和软件系统的有效运行。
二、软件开辟管理规范1.项目立项和需求分析阶段1.1 确定项目目标和范围，并编制详细的项目计划。
1.2 进行全面的需求分析和功能规格说明书编写，确保需求的准确性和完整性。
1.3 制定项目开辟团队组织结构和人员分工，并明确各个角色的职责和权限。
2.软件设计和编码阶段2.1 根据需求分析阶段的结果，进行系统架构设计和模块划分。
2.2 编写详细的设计文档，包括系统结构、模块接口和数据结构等。
2.3 严格遵循编码规范，包括命名规则、注释要求和代码风格等。
2.4 进行代码审查和单元测试，确保代码的质量和可维护性。
3.软件测试和质量保证阶段3.1 制定详细的测试计划和测试用例，覆盖所有功能和边界条件。
3.2 进行单元测试、集成测试和系统测试，确保软件的功能完整性和稳定性。
3.3 进行性能测试和安全测试，评估软件的性能和安全性。
3.4 进行用户验收测试，确保软件满足用户需求和期望。
4.软件发布和维护阶段4.1 制定软件发布计划，包括版本管理和发布流程。
4.2 进行软件安装和配置，确保软件能够正确运行。
4.3 提供及时的技术支持和维护服务，解决用户反馈的问题和bug。
4.4 定期进行软件升级和补丁发布，修复已知的漏洞和问题。
三、软件使用管理规范1.软件采购和授权管理1.1 制定软件采购流程和标准，确保软件的合法性和正版性。
1.2 统一管理软件授权和许可证，确保软件的合规性和有效性。
1.3 定期进行软件资产清查和更新，确保软件的使用授权和数量的准确性。
2.软件安装和配置管理2.1 制定软件安装和配置规范，包括硬件要求和操作系统要求等。
2.2 进行软件安装和配置前的准备工作，包括系统备份和环境检查等。
软件管理制度
软件管理制度软件管理制度是指为了保证软件的安全性、可靠性和有效性，规范软件的开发、测试、上线、维护等全过程进行管理的一套制度。
以下是软件管理制度的主要内容：一、软件开发管理：1. 软件需求管理：明确软件需求，确保开发的软件功能符合用户需求。
2. 软件设计管理：制定软件设计规范，确保软件结构合理、易于维护。
3. 软件编码管理：规范编程风格，确保程序的可读性、可维护性。
4. 软件测试管理：制定测试计划和测试用例，保证软件质量和稳定性。
5. 软件文档管理：要求编写软件设计文档、用户手册等，确保软件的理解和使用。
二、软件配置管理：1. 版本管理：规定软件版本号的格式和变更规则，确保版本控制的一致性。
2. 配置项管理：对软件的源代码、可执行文件、文档等进行配置管理，确保文件的完整性和一致性。
3. 变更控制管理：规定软件变更流程和权限，确保变更的合理性和可控性。
三、软件发布管理：1. 版本发布：制定软件发布的时间和流程，确保软件发布的及时性和准确性。
2. 发布验证：对发布的软件进行功能验证和性能测试，确保发布的软件符合要求。
3. 发布文档：编写软件发布文档，包括发布说明和操作手册等。
四、软件维护管理：1. 故障处理：制定故障处理流程，包括故障报告、故障分析和故障修复等。
2. 反馈处理：接受用户反馈并进行处理，包括问题记录、解答和建议等。
3. 维护更新：对软件进行定期维护和更新，确保软件的持续运行和功能完善。
五、软件安全管理：1. 安全策略：制定软件安全策略，包括用户权限管理、数据加密和漏洞修复等。
2. 安全测试：进行软件安全测试，发现并修复软件中的安全漏洞。
3. 安全审计：定期对软件进行安全审计，查找潜在的安全风险并进行整改。
六、培训和考核：1. 培训计划：制定培训计划，培养开发人员和测试人员的能力和素质。
2. 考核评估：对软件开发人员和测试人员进行考核评估，确保团队的专业水平和工作质量。
通过建立和执行软件管理制度，能够规范软件开发和维护的各个环节，提高软件的质量和信用度，增强软件的可靠性和安全性。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
配置管理计划编写规范
文件修改控制
目录
1. 目的
2. 适用范围
3. 术语及缩略语
4. 编写规范
4.1 组织与职责
4.2 配置标识
4.3 配置控制
4.4 配置状态报告
4.5 配置审核
5. 引用文件
6. 附录
1. 目的
确定实施配置管理活动的具体组织及其职责，明确配置管理活动的具体内容，即对哪些配置项进行标识、控制、状态记录、审核，编制配置管理里程碑。
2. 适用范围
适用于项目策划阶段所要求的《配置管理计划》的编写。
3. 术语及缩略语
本程序采用NQ402100《质量手册》中的术语和缩略语及其定义。
4. 编写规范
《配置管理计划》就是要明确如何实施配置管理活动。
该计划包括的内容如下：要执行的配置管理活动，所需的组织及其各自的职责，配置管理活动的里程碑。
下面是《配置管理计划》的具体内容。
4.1 组织与职责
明确指派负有下列职责的各类人员：
负责《配置管理计划》的审批、实施与更改跟踪的软件配置管理经理SCMM；
在整个软件生命过程中按照《配置管理计划》执行配置管理活动的软件配置管
理负责人SCML；
4.2 配置标识
4.2.1 列出要标识的所有配置项及其相应的标识规范。
例如，对软件工具、硬件设备、
开发计划、计算机程序等如何标识。
4.2.2 基准配置项的标识
识别每一基准配置项，并标识下列信息：何时及如何提交、批准人和验证人、
目的、提交方式（软件或文档）及版本号。
4.2.3 文档库内容
标识和控制规范、文档库的数目及类型、备份及作废计划和程序、任何损失的
恢复过程、文档保留程序、什么文档要保留和谁保留及保留多长时间、信息是
在线还是脱机保留以及保留介质。
4.3 配置控制。