问题和场景

1.多人修改同样的源代码文件的时候，前者修改的内容往往被冲掉 (检入检出)
2.维护版本发布后发现两周前修改的一个Bug引入新问题，无法快速定位文件 (版本树，变更集)
3.新版本和维护版本都在做，有几个Bug修改需要单独部署，很难操作?(分支和Deliver)
4.程序打包或每日编译经常失败，而且在失败后无法快速定位到责任人 (检入检出,版本树)
5.设计人员依据进行设计的需求文档不是当初评审通过的版本 (配置项和基线)
6.无法在项目计划阶段定义出相关的该版本交付物 (配置项清单)
7.测试依据进行测试用例编写的需求和设计人员依据进行设计需求不一致 (基线)
8.项目经理无法清楚的知道项目成员任务是否完成 (任务,配置项和工作包对应)
9.无法在需求的时候生成项目的老版本 (基线,配置项一致性)

配置管理概念

PMI和CMMI都认为配置管理是包含了变更管理的。

软件配置管理是一门应用技术、管理和监督相结合的学科，通过标识和文档来记录配置项的功能和物理特性，控制这些特性的变更，记录和报告变更的过程和状态，并验证它们与需求是否一致。（摘自IEEE定义）

软件配置管理是一种标识、组织和控制修改的技术，目的是协调软件开发，使得混乱减到最小，使错误达到最小并最有效地提高生产效率。《SCM Coordination for Team Productivity》

实施CM的目的是要对软件系统不断变化的配置进行管理，保证工作产品在整个生命周期的一致性(Page 123)

配置管理的基本功能(标识配置项,控制变更,状况监控,配置管理审核)

1.给出程序状态(何时测试或发布版本)
2.给出程序的最新版本(随时可以获取最新版本)
3.处理并发修改(CC提供Merge功能)
4.取消一个已经实施的变更或Bug的所有修改 (变更集,undo)
5.提供变更请求和程序变更间的可跟踪性 (变更集,CC和CQ关联)
6.显示相关的变更(关联变更，关联变更措施，关联活动)
7.收集当前系统所有配置项信息，以便于系统崩溃时候恢复 (重要)

重要概念说明

里程碑：某一个阶段，经过正式的评审，验证，确认或测试后，大家一致认为已经完成和达到目标。

基线：要对达到里程碑的一组特定工件做个标记或快照。1)代表这组工作产品的一致性 2)代表这组工作产品可以做为下一个阶段的工作依据。 3)对于基线工作产品的修改都必须严格受到变更控制。

配置项:受SCM管理和控制的工作产品(文档，代码，数据,环境)

配置项:对项目或产品至关重要的交付物，需要进行版本和变更管理的交付物。

配置物理审核：仅审核配置项是否存在，物理路径，文件名称等是否和配置项清单一致。

配置功能审核：确定配置项目是否实现了特定的功能需求，审核配置项间的可追踪性。

版本控制：有效的记录配置项的历史修改记录和情况。

大版本和小版本：一般的检入和检出应该是升级小版本的概念，而通过CQ进行变更应该升级大版本。现在CC暂无该概念

访问控制机制：现在CC只能控制到VOB的读写，粒度太大。无法根本防止源代码泄露

配置管理计划的内容

配置项的识别：广义和狭义配置项。变更受控和仅归档为目的要分清楚。现在配置项识别一般是架构人员来做，配置管理员一般很难识别出项目细粒度的配置项信息。

CC相关规约：CC的目录结构，命名和编码规则，访问控制。(6.1节,6.2节)

变更控制流程和规则：变更的最终对象是配置项，因此变更的内容必须是受控的。(6.4节)

基线管理：依据在项目主计划中的基线规划和配置项清单

配置状态报告：基线，配置项，变更和版本发布的状态 (最好在项目周期内均匀安排时间点)

配置审核报告：分为物理审核，功能审核和基线审核(现在情况基本是物理审核和基线审核，审核一般在提交基线发布申请时候做。而功能审核暂时没有操作起来)

执行配置控制

1.对配置项进行修改时候必须先检出，对基线配置项修改走变更
2.活动和配置项要严格对应起来(变更集)
3.变更程序(需求变更->预审意见->CCB会议->变更措施)
4.常见变更对象(变更请求，变更提议，变更调查，变更单，变更活动)

状态监督和审计

1.基线，配置项状态是下个阶段的重要依据和保证
2.变更状态是变更是否完成依据
3.配置审计：由CM来做主要是配置项的状态和物理位置
评审区域和用户区域：InfoSys对评审区域还单独进行了控制