下载文档原格式
水利工程建设注册造价工程师持续教育系统软件配置管理计划中水全球（北京）科技有限企业二零壹零年伍月份目录1 前言1 ..............................................................................................................目的 (1)1定义 .....................................................................................................参照资料 (1)2 管理2 ..............................................................................................................机构 (2)任务 (3)3职责 .....................................................................................................接口控制 (4)软件配置管理计划的实现 (6)合用的标准、条例和商定 (7)3 软件配置管理活动 (8)配置表记 (8)文档 (8)程序 (8)3.1.3 各种基线 (8)配置控制 (9)配置状态审计 (9)配置的检查和评审 (10)4 工具、技术和方法能否有 ? (10)5.记录的保护和保留 (11)1前言1.1 目的本计划的目的在于对所开发的水利工程建设注册造价工程师继续教育系统软件规定各样必需的配置管理条款，以保证所交托的水利工程建设注册造价工程师持续教育系统软件能够知足项目拜托书中规定的各样原则需求，能够知足本项目整体组拟订的且经领导小组批准的软件系统需求规格说明书中规定的各项详细需求。
XXXX项目配置管理计划简介本计划描述了配置组织结构以及贯穿项目组日常工作，由项目组识别并定义的一系列的配置项的实践过程。
1.1文档目的定义配置管理的职责、所需资源以及描述实施过程中一系列的配置管理活动，指导项目软件配置管理工作。
1.2适用范围本计划适用于XXXX项目的软件配置管理活动的制定。
1.3项目背景描述略。
1.4术语与缩略语软件配置管理：简称 SCM（Software Configuration Management），是在项目开发中，标识、控制和管理软件变更的一种管理。
配置项目标识：（Configuration Indentification）对软件项目在开发过程中的资源进行标识，以便标识。
配置审计：（Configuration Audit）对软件配置管理过程中的行动进行检查。
资源2.1配置管理组织架构图配置管理的组织架构主要角色有公司的配置管理（Configuration Management，CM），项目的配置管理（Configuration Management，CM），项目经理（Project manager，PM），以及配置管理审批人和项目成员。
图1 组织架构图2.2关键角色和职责配置管理员项目组中负责配置管理工作的角色，负责计划和控制配置管理过程。
在某一开发阶段通过评审或某一质量检查点通过审核后，配置管理员负责统计添加或修改相关产出物的最新有效版本以及审核证明。
配置管理委员会（CCB）CCB 是一个虚拟的小组，对配置管理各项活动拥有决策权（例如审批配置管理计划，审批配置项变更请求等）。
CCB 的决策采用“少数服从多数”的原则。
主要成员：甲方项目经理、高层领导、需求专家、架构专家、配置管理人员、测试专家和质量保证人员。
2.3所需资源表1 配置管理工具及辅助软件工具名称发布公司用途GitLab GitLab 配置库管理工具，主要源代码SVN Apache软件基金会配置库管理工具，主要是文档Microsoft Office Microsoft 办公工具Microsoft Project Microsoft 办公工具SCM 活动3.1配置库的创建和授权项目配置库创建项目配置库申请审批通过后，项目经理通过一体化运维平台的工作单给项目组配置管理员，要求开通配置库，并说明项目人员权限。
测试管理案例之一某软件公司在开发一个城镇居民保险系统时，为了追赶进度，开发人员与测试人员都没有介入单元测试和集成测试工作。
系统测试阶段，测试人员针对界面进行功能测试，借助缺陷管理工具，测试人员和开发人员交互进行测试与缺陷修复工作。
期间发现“扭转文档无法归档”等功能出现严重错误，开发人员在修改时，因为难度大决定暂停修改，得到测试人员认可。
在产品发布前，该问题在开发环境下得到解决。
测试人员在开发环境下进行了回归测试，回归测试结束后，开发人员直接把开发环境下的产品打包，发送给客户。
开发人员和测试人员的做法是否存在不合理的地方？不合理之一：测试介入太晚分析：不合理之二：系统测试方法不合理分析：系统功能测试应该追溯到用户需求，针对界面进行功能测试是错误的。
不合理之三：缺陷管理不合理分析：缺陷权限控制不合理：Ø开发工程师无权决定是否延期或者暂停修改某一缺陷Ø测试工程师认可缺陷的决定也是不合理的缺陷跟踪不合理：测试工程师应该跟踪缺陷状态，直至确定修改后关闭缺陷，才是完成了测试任务。
而不是执行测试发现缺陷就完成了任务，所有的缺陷应该经过验证后才可以发布产品。
缺少缺陷审核：产品发布前，应该对发现的缺陷进行评审，根据修改结果决定是否可以发布。
不合理之四：产品发布不合理分析：产品最后由开发人员直接发布不合理。
实际最后发布的产品应该从产品库中提取，而且基线库中的产品应该是最后经过测试的。
测试管理案例之二某企业有三大产品线，拥有强大的研发团队，测试部门约有8人，没有经过测试技术和测试管理的专门培训，测试类型主要是功能测试，测试阶段主要集中在产品上线前。
这种运作模式，企业和用户对产品质量会满意吗？如果不满意，我们应该采取哪些有些有效的方法来改进？改进方法之一：提高测试团队规模和研发团队相比，测试团队应该占有相当的比例，建议6到8比1。
目前的现状是用户需求多样化，用户看重产品的质量改进方法之二：提高测试团队技能产品的质量特性，不仅仅包括功能性，还包括可靠性、易用性、效率、安全性、维护性以及可移植性等等。
文档编号:配置计划<V1. 0>编写人:编写日期:部 n：审核人:审核日期:修订页1简介 ............................1.1目的.......................1.2适用范围...................1.3参考资料...................1.4职责描述...................2配置管理活动 ....................2.1软件资源与硬件资源...........2.2标识配置项.................2.2.1配置项版本标识.......2.2.2配置项需称格式说明2.2.3配置项.............2.3项目基线管理...............2.3.1基线列表...........2.3.2基线建立流程.......2.3.3基线的变更控制2.4发布管理...................2.5配置审讣...................2.6人员安排与时间安排......... 3数据资料管理计划 ................ 2 2 2 2 2 2 2 3 3 3 4 4 41简介1.1目的本讣划是用来指导项目配置管理作业的过程与步骤，以便全面地管理、保存软件生命周期各个配置项，监控各配置项的状态，让小组所有成员能及时了解软件基线的状态和内容，从而实现对软件过程的控制，持续改进软件流程，保证软件产品质量、降低风险，实现项目规划的所有需求，同时提高开发团队的工作效率、降低软件开发成本。
1.2适用范围本项目中纳入配這管理的活动：项目笛理文档（如项目il划、配置讣划等）、项目技术文档（需求规格说明书、概要设讣等）、源程序及模块文档、基线、产品、用户文档、项目工具。
1.3参考资料《配宜管理指南》1.4职责描述表」2配置管理活动配置活动的目的是向项目组每一个人传达在本项目中如何进行配置。
软件测试计划范文3篇篇一:软件测试计划1(简介1.1目的,项目名称,的这一“测试计划”文档有助于实现以下目标: [确定现有项目的信息和应测试的软件构件。
列出推荐的测试需求。
推荐可采用的测试策略，并对这些策略加以说明。
确定所需的资源，并对测试的工作量进行估计。
列出测试项目的可交付元素]1.2背景[对测试对象及其目标进行简要说明。
需要包括的信息有:主要的功能和性能、测试对象的构架以及项目的简史。
]1.3范围[描述测试的各个阶段，并说明本计划所针对的测试类型。
简要地列出测试对象中将接受测试或将不接受测试的那些性能和功能。
如果在编写此文档的过程中做出的某些假设可能会影响测试设计、开发或实施，则列出所有这些假设。
列出可能会影响测试设计、开发或实施的所有风险或意外事件。
列出可能会影响测试设计、开发或实施的所有约束。
2. 测试参考文档和测试提交文档2.1测试参考文档下表列出了制定测试计划时所使用的文档，并标明了各文档的可用性:[注:可适当地删除或添加文档项。
]文档、已创建或可用、已被接收或已经过复审、作者或可行性分析报告、是? 否?、是? 否?需求规格说明书、是? 否?、是? 否?软件概要设计、是? 否?、是? 否?软件详细设计、是? 否?、是? 否?软件测试需求、是? 否?、是? 否?测试时间表及人员安排、是? 否?、是? 否?用户操作手册、是? 否?、是? 否?安装指南、是? 否?、是? 否?2.2测试提交文档[下面应当列出在测试阶段结束后，所有可提交的文档]例如:测试报告，测试用例3.测试进度测试活动、计划开始日期、实际开始日期、结束日期、完成人员制定测试计划设计测试用例集成测试系统测试性能测试安装测试用户验收测试对测试进行评估产品发布4.测试资源4.1人力资源下表列出了在此项目的人员配备方面所作的各种假定。
[注:可适当地删除或添加角色项。
]角色所推荐的最少资源具体职责或注释4.2测试环境软件描述硬件描述4.3测试工具此项目将列出测试使用的工具:用途工具生产厂商/自产版本5.测试风险评估、优先级[简要描述测试阶段的风险和处理的优先级]6.测试策略[测试策略提供了对测试对象进行测试的推荐方法。
软件配置管理计划模板文档标识：当前版本：当前状态：发布日期：目录1概述 (3)1.1目的和范围 (3)1.2软件配置管理计划维护 (3)1.3参考资料 (3)2角色和职责 (3)2.1软件配置管理代表 (3)2.2配置控制委员会 (3)2.3项目开发组 (3)2.4项目经理 (4)3配置管理环境 (4)3.1文档工具 (4)3.2软件配置管理工具 (4)3.3配置管理服务器 (4)4配置管理活动 (4)4.1配置标识 (4)4.1.1 标识方法 (4)4.1.2 配置项标识及存储 (5)4.1.3 软件产品 (5)4.1.4 配置基线定义及存储 (5)4.2配置库管理 (6)4.2.1 配置库结构 (6)4.2.2 权限层次 (6)4.2.3 注册用户 (6)4.2.4 备份机制 (6)4.3配置控制 (7)4.4配置状态统计 (7)4.4.1 配置控制委员会会议记录 (7)4.4.2 变更请求状态 (7)4.4.3 配置项状态 (7)4.5基线审核 (8)5配置管理审核 (8)6配置管理代表主要活动时间表 (8)7配置控制委员会主要活动时间表 (8)1 概述1.1 目的和范围本节描述软件配置管理计划的目的和范围。
1.2 软件配置管理计划维护本节将描述该计划在何种情况下需要被更新，以及如何更新。
例如:此软件配置管理计划由{项目组}负责开发和维护。
当出现新的问题或需要更改已存在问题时，需按《变更控制规程》进行更新，并由{项目组}负责完成。
1.3 参考资料用实际引用的文档替代/添加在下面的文档后。
例如：1.软件配置管理过程2 角色和职责2.1 软件配置管理代表2.2 配置控制委员会在此处写配置控制委员会主席和成员的名字。
2.3 项目开发组2.4 项目经理3 配置管理环境3.1 文档工具{项目名称}项目的所有文档由下列办公系统软件生成，或由标准的ASCII文本编辑器（例3.2 软件配置管理工具3.3 配置管理服务器4 配置管理活动4.1 配置标识4.1.1 标识方法以下4.1.2和4.1.3节中所列各配置项需要分配唯一的标识，具体的标识方法可以参考新宇软件开发中心《软件配置管理过程》中3.3节内容。
目次1 范围 (1)1.1 标识 (1)1.2 委托与测试单位相关信息 (1)1.3 系统概述 (1)1.3.1 功能概述 (1)1.3.2 接口描述 (1)1.3.3 性能指标 (1)1.3.4 被测件的基本信息 (1)1.4 文档概述 (2)1.5 与其它计划的关系 (2)2 依据和引用文档 (3)3 测试总体要求 (3)3.1 测试级 (3)3.2 测试类型及测试要求 (3)3.3 测试技术和方法 (3)3.4 测试总体策略 (4)3.5 集成策略与集成过程（适用于系统测试） (4)3.6 测试项说明 (5)4 测试资源 (5)4.1 软件项 (5)4.2 硬件和固件项 (6)4.3 软硬件关系 (6)4.4 安装、测试与控制 (6)4.5 测试环境的差异性分析和有效性说明 (7)4.6 测试参与组织、人员及分工 (8)4.7 人员技能要求与培训 (10)5 测试进度及项目管理 (12)5.1 测试进度及工作量评估 (12)5.2 项目跟踪与控制 (12)5.3 受控产品清单 (13)5.4 配置管理计划 (13)5.5 质量保证计划 (13)6 风险分析 (13)7 数据记录、整理和分析 (14)8 软件评价准则和方法 (15)9 测试终止条件 (15)9.1 测试正常终止 (15)9.2 测试异常终止 (16)10 需求的可追溯性 (16)11 注释 (16)附录A 缺陷分类表 (17)附录B 缺陷严重程度定义表 (18)图 1 测试环境示意图 (5)表1 被测件清单 (1)表2 测试环境的软件项 (6)表3 测试环境的硬件项 (6)表4 测试环境的软硬件关系 (6)表5 安装和测试计划 (6)表6 控制和维护计划 (7)表7 测试参与的人员分工 (8)表8 技能现状分析表 (10)表9 培训计划表 (11)表10 工作进度安排 (12)表11 测试监督内容与方式 (12)表12 与测试需求的追踪关系 (13)表13 测试受控产品清单 (13)表14 软件测试风险 (13)1 范围1.1 标识a)文档标识号：XTxxx-xxx-xxSTP；b)标题：xxxx软件配置项测试计划；c)缩略名：xxxx缩略为xxxxx；d)版本号：本文档版本号V1.0；e)本文档适用软件配置项：xxxx软件；本文档适用于xxxx软件的CSCI测试过程。
配置管理计划样例软件开发-CAL-FENGHAI-(2020YEAR-YICAI)_JINGBIAN【用户名称】神州数码信息系统有限公司密级：普通***项目软件配置管理计划文档编号：项目名称：编写：编写日期：审核：审核日期：批准：批准日期：修订文档历史记录目录1 前言......................................................................................................... 错误!未定义书签。
目标.................................................................................................. 错误!未定义书签。
适用范围.......................................................................................... 错误!未定义书签。
术语与简写...................................................................................... 错误!未定义书签。
参考文件.......................................................................................... 错误!未定义书签。
2 组织结构和职责..................................................................................... 错误!未定义书签。
CCB成员及职责 .............................................................................. 错误!未定义书签。
软件配置管理计划XXXX科技有限公司XXXX年XX月目录1引言 (3)1.1 文档概述 (3)1.2 编写目的 (3)1.3 编写范围 (3)1.4 术语定义 (3)1.5 参考资料 (4)2 软件配置管理 (5)2.1 机构 (5)2.2 任务 (5)2.3 职责 (5)2.4 接口控制 (6)2.5 实现 (6)2.6 适用的标准、条例和约定 (6)3 软件配置管理活动 (7)3.1 配置标识 (7)3.1.1 标识方法 (7)3.1.2 各类基线 (7)3.2 配置和变更控制 (7)3.3 配置状态审计 (8)3.4 配置的检查和评审 (9)4 工具、技术和方法 (9)5 里程碑 (9)6 培训和资源 (10)7 对供货单位的控制 (10)8 记录的收集、维护和保存 (10)1引言说明：配置管理计划的简介应提供整个文档的概述。
它应包括此配置管理计划的目的、范围、定义、术语定义、参考资料和概述。
1.1 文档概述说明：本小节应说明此配置管理计划中其他部分所包含的内容，并解释文档的组织方式。
1.2 编写目的说明：阐明此配置管理计划的目的。
1.3 编写范围说明：简要说明此配置管理计划的范围；它的相关模型，以及受到此文档影响的任何其他事物。
1.4 术语定义说明：本小节应提供正确理解此配置管理计划所需的全部术语、首字母缩写词和缩略语的定义。
●软件配置管理，简称SCM(Software Configuration Management的缩写)，是在团队开发中，标识、控制和管理软件变更的一种管理。
配置管理的使用取决于项目规模和复杂性以及风险水平。
软件的规模越大，配置管理就显得越重要。
●基线(baseline)，是项目储存库中每个工件版本在特定时期的一个“快照”。
它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。
建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。
软件测试计划范例.docx测试计划产品名称：工程承担部门撰写人（签名）完成日期本文档使用部门评审负责人（签名）评审日期版本三普销售助手规范版研发部白红勃测试部日期版本说明作者目录1.概述 (1)产品简介1范围 1限制条件1参考文档12.约定2测试目标2接收规范2资源和工具2资源 2工具 2送测要求2编号规则23.测试种类及测试规范3测试种类3测试方法及规范3功能测试3业务测试3压力测试3安装测试3验收测试34.测试重点及顺序4预测风险4测试重点4功能测试4业务测试45.暂停规范和再启动要求56.测试任务和进度67.测试提交物71.概述1.1 产品简介本次开发是在销售助手一期的基础上进行的后续开发，包括新增客服功能模块、解决一期遗留的售前部分问题、完成必要的库房经管功能。
二期结束后产品就成为一个比较完整的销售经管软件。
1.2 范围本测试计划是针对<销售助手二期概要设计说明书>中规定内容的测试计划，包括：改进后的报价书改进后的客户关怀销售机会中新增加的客户反馈销售机会中新增加的客户组织分析销售机会中改进的竞争经管（待定）销售机会中改进的联系人改进后的产品和价格配制器新增的销售知识库新增的联系活动经管新增的客户请求模块新增的客服活动模块新增的客服合同模块新增的客服计划模块新增的客服知识库模块新增的完成关联任务模块公共部分新加或改进的日历浏览数据公共部分新加或改进的报表功能公共部分新加或改进的个人事务中心1.3 限制条件本测试计划受限于产品开发人员提交测试的内容和时间的事实。
根据开发人员提交模块的实际情况，本计划会做出相应修改。
1.4 参考文档序号名称作者备注1.二期概要设计说明书2.客服物理模型3.日历模块详细设计说明4.个人事务中心模块详细设计说明5.客服产品缺陷详细设计说明6.客户请求详细设计说明7.客服活动详细设计说明8.产品和价格配制器详细设计说明9.完成关联任务详细设计说明10.客服合同详细设计说明11.客服计划详细设计说明12.客服报表详细设计说明13.客服知识库详细设计说明14.联系活动经管详细设计说明15.商品组装方案详细设计说明16.销售机会修改详细设计说明17.选择商品修改详细设计说明18.销售知识库详细设计说明19.客户关怀修改详细设计说明2.约定2.1 测试目标通过测试，达到以下目标：测试已实现的产品是否达到设计的要求，包括：各个功能点是否以实现，业务流程是否正确。
酒店管理系统 卷 号 卷内编号
密 级
分 类:专题计划 使用者: 项目经理、配置变更控制经理、集成员、项目组成员
配置管理计划 Version 1.0
项 目 承 担 部 门 ： 配置管理部门 撰 写 人（签名）： 完 成 日 期 ： 2010/7/18 本文档 使 用部门： □主管领导 ■项目组 □客户（市场） □维护人员 □用户
评审负责人（签名）： 评 审 日 期：
文档信息 标题: 配置管理计划 作者: 创建日期:2010/7/18 上次更新日期: 2010/7/18 版本: Version 1.0
部门名称: swjtu-Java-02
修订文档历史记录 日期 版本 说明 作者 2010/7/18 Version 1.0 创建文档 2010/7/22 Version 1.1 修改文档 目录 1. 简介 4 1.1 目的 4 1.2 范围 4 1.3 定义、首字母缩写词和缩略语 4 1.4 参考资料 4 4
2. 软件配置管理 4 2.1 组织、职责和接口 4 2.2 工具、环境和基础设施 4
3. 配置管理活动 6 3.1 配置标识 6 3.1.1 标识方法 6 3.1.2 项目基线 6 3.2 配置和变更控制 8 3.2.1 变更请求的处理和审批 8 3.2.2 变更控制委员会 (CCB) 10 3.3 配置状态统计 11 3.3.1 项目介质存储和发布进程 11 3.3.2 报告和审计 11
4. 里程碑 11 5. 培训和资源 12 6. 分包商和厂商软件控制 错误!未定义书签。 配置管理计划 1. 简介 项目CM计划说明在产品生命周期中将执行的所有与CM相关的活动。它详细说明了活动时间表、分配的职责以及必需的资源（包括人员、工具和计算机设备）。
1.1 目的 CM 计划的目的在于，定义或参考那些描述要在软件产品开发中执行配置和变更控制管理 (CM) 方式的步骤和活动。
1.2 范围 本规范规定了在制订软件配置管理计划时应该遵循的统一的基本要求。 本规范适用于软件特别是重要软件的配置管理计划的制订工作。对于非重要软件或已开发好的软件，可以采用本规范规定的要求的子集。
1.3 定义、首字母缩写词和缩略语 CCB - configuration control board 变更（或配置）控制委员会 CI - configuration item 配置项 CM - configuration management 配置管理 Baseline： 基线。 PCA：物理审计，在配置管理系统中建立基线的工件是否为“正确”版本。 FCA：功能审计，是核实软件配置项的实际性能是否符合它的需求。 CMP - configuration management plan 配置管理计划 CR - change request 变更请求 SCM - software configuration management 软件配置管理 任意角色 – 项目中所有角色
1.4 参考资料 《Rational Unified Process 2000》 《SDP Plan》 《Develop Case》
2. 软件配置管理 2.1 组织、职责和接口
角色 相关人员 职责 接口 CCB 该委员会监督变更流程，由开发人员和用户的代表组成。 与任意角色：任意角色提出变更请求，需提交给CCB，对变更请求进行处理后，将结果通知给提出者。 配置经理 配置经理负责为产品开发团队提供全面的配置管理 (CM) 基础设施和环境。CM 的作用是支持产品开发行为，使开发人员和集成员有适当工作区来构建和测试其工件，并且使所有工件均可根据需要包含在部署单元中。配置经理还必须确保 CM 环境有利于进行产品复审、更改和缺陷跟踪等活动。配置经理还负责撰写 CM 计划并汇报基于“变更请求”的进度统计信息。发布基线 与项目经理：CM计划需要参照SDP计划，而且SDP又参照CM计划。SCM经理每周/每阶段都要提供系统的配置状态报告给项目经理。 与集成员： CM经理创建配置管理库，而集成员创建集成工作区。集成员创建基线和提升基线，由SCM经理管理基线。 与部署经理：SCM经理创建部署单元，需要部署计划。 与架构设计师：SCM经理创建CM环境，需要实施模型。 与任意角色：任意角色创建开发工作区，需要配置库。 与系统管理员：创建CM环境时，需要系统管理员提供硬件和网络基础设施。
与组织SCM管理员：在每一阶段基线完成后提交基线工件。
与评审协调员：接收评审协调员提交的评审结果工件和评审表。
与SQA人员：配合SQA人员活动。 任意角色 项目组所有成员 任何角色均可以“检入”和“检出”任何与产品相关的工件，以便在配置控制系统中进行维护。此外，任意角色都可以提交变更请求，并且对它们所拥有的变更请求进行更新。
2.2 工具、环境和基础设施 1.工具 类型 使用时期 工具 原因 配置管理 产品开发全程 Svn Svn简单，功能强大。
2.CM环境和基础设施
1）产品数据量的预期大小：我们期望本项目至少有150个文件，50M的磁盘空间。 2）产品团队的分配： 角色 成员名单 角色说明 PM 项目经理 SA 需求分析师 SE 设计分析师 TE 测试工程师 CM 配置管理员 PPQA 产品和质量保证
服务器和客户机的实际位置：1台。2G内存、160G硬盘。Win7。服务器位置在C2-6,客户端在C2-1.3.4.5.7.8.9.10
3. 配置管理活动 3.1 配置标识 3.1.1 标识方法 最终的工件的命名方式是 大写字母+缩写+编号+名称 例：HMS-CM-101-配置管理计划 相应的工件的中间版本命名方式是以对应的阶段大写字母缩写加类别大写缩写加版本编号命名 发布标志为产品缩写加版本号,阶段发布为阶段号加版本号
3.1.2 工件存储目录及分类 项目开发过程产生的工件由相应的负责人及时上传至SVN服务器，由配置管理员统一管理。 SVN服务器文件存放目录分类如下图
3.1.3 文件上传管理 所有模块负责人必须与每日工作结束之前上传当日工作内容上传至SVN服务器。 所有上传工件必须符合标识方法中的命名方式。
3.1.3项目基线
基线名称 基线标识 产出时机 计划基线 JH-01 计划阶段结束 需求基线 XQ-01 需求分析阶段结束
设计基线 SJ-02 设计阶段结束 产品基线 CP-03 实现部署阶段结束
基线创建 非代码类基线：由配置经理根据《开发案例》创建 代码类基线：由集成员根据产品架构文档创建
3.2 配置和变更控制 3.2.1 变更请求的处理和审批 软件配置的变更管理适用于本项目的所有文档和代码，其中包括本项目的各个运行软件，也包括为本项目专门开发的支持软件。
变更请求表单是一个正式提交的工件，用于在整个项目的生命周期内跟踪所有的请求（包括新特性、扩展请求、缺陷、变更的需求等）与相关的状态信息。所有变更历史记录，包括所有状态变更及变更的日期和原因，都将随 CR 一起保存。进行多次复审和结束项目时都可使用此信息。
变更过程中的活动 活动 角色 内容 提交变更请求 提交者 项目的任何涉众均可提交变更请求 (CR)。通过将变更请求状态设置为已提交，变更请求被记录到变更请求追踪系统中（例如 ClearQuest）并放置到 CCB 复审队列中。 复审变更请求 CCB 此活动的作用是复审已提交的变更请求。在 CCB 复审会议中对变更请求的内容进行初始复审，以确定它是否为有效请求。如果是，则基于小组所确定的优先级、时间表、资源、努力程度、风险、严重性以及其他任何相关的标准，判定该变更是在当前发布版的范围之内还是范围之外。 确认重复或拒绝 CCB 代表 如果怀疑某个变更请求为重复的请求或已拒绝的无效请求（例如，由于操作符错误、无法重现、工作方式等），将指定一个 CCB 代表来确认重复或已拒绝的变更请求。如果需要的话，该代表还从提交者处收集更多信息。 更新变更请求 提交者 如果评估变更请求时需要更多的信息（详细信息），或者如果变更请求在流程中的某个时刻遭到拒绝（例如，被确认为是重复、已拒绝等），那么将通知提交者，并用新信息更新变更请求。然后将已更新的变更请求重新提交给 CCB 复审队列，以考虑新的数据。 分配工作与安排工作时间 项目经理 一旦变更请求被置为已打开，项目经理就将根据请求的类型（例如，扩展请求、缺陷、文档变更、测试缺陷等）把工作分配给合适的角色，并对项目时间表做必要的更新。 进行变更 指定的角色 指定的角色执行在流程的有关部分中指定的活动集（例如，需求、分析设计、实施、制作用户支持材料、设计测试等），以进行所请求的变更。 这些活动将包括常规开发流程中所述的所
