记录12_7.24～7.25

在这段时间里，我们继续进行对软件配置管理的学习：

基线变更管理

变更批准或拒绝
根据评估结果对变更作出决策：
直接实现变更；挂起或延迟变更；拒绝变更
对于批准的变更，要确定其实现进度：
立即实现变更；在特定的日期实现变更；在软件另外的版本中实现
变更实现

配置审核

配置管理活动审核：

确保所有配置管理活动符合已批准的软件配置管理规程

基线审核：

审核基线配置项的完整性和一致性，从而保证基线配置项可被正确地构造。

配置状态统计和报告

变更请求的数量。变更管理活动的执行情况。
配置管理系统存储量的变化。配置管理系统和SCCB在运作中发生异常的次数

活动六个方面

CMM/CMMI将软件配置管理的活动分为6个方面，每个方面又再进行了细分

SCM过程管理；软件配置标识；软件配置控制；软件配置状态统计；软件配置审计；软件发布管理和交付

在CMM和CMMI中，将配置管理的目的定义为"建立和维护产品的完整性"，

配置完整性（对标准的理解）

产品完整性：项目提交的工作成果是"产品集合完整、子产品正确"的
产品集合完整：产品包含的子产品（配置项）是完整的
子产品正确：子产品（配置项）达到了需求要求，满足标准、规程的要求

三库管理：

三库的概念源自CMM/CMMI，即开发库、受控库和产品库。配置项在三库之间迁移，一级比一级的控制更严格。
软件开发组日常的工作在开发库中开展，当工作达到里程碑时，再迁移到受控库，在受控库中经过更严格的测试后，再上升到产品库，最后发布。

在实践中，三库常常被实现为物理上的三库，而不是通过逻辑的方式来实现，三库物理隔离带来的最大问题是配置项失去了历史可追溯性

实现三库的指导思想应该是逻辑上独立，物理上在一起，通过权限与流程的控制来实现配置项在不同库之间的流转，以及相应角色的人员对相应库的访问。

CMM2在配置管理方面主要针对于实现部分;CMM3将配置管理扩展到需求、规格说明、设计和工具

SCM意义：

记录软件产品的演化过程；
确保软件开发者在软件生命周期中的各个阶段都能得到精确的产品配置；
最终保证软件产品的完整性、一致性、追朔性、可控性;。

建立基线的好处

重现性；可追踪性；版本隔离。

基线管理的步骤：

(1) 在开发前确定基线的"配置"；

(2) 基线批准前，根据"配置"检查配置项是否齐备；

(3) 对各个配置项，确认其版本的正确性；

(4) 对每个配置项建立基线标志；

(5) 基线变更管理；(6) 基线的各类报告和审计信息。

变更管理的流程：

（获得）提出变更请求；由CCB审核并决定是否批准；

为（被接受）修改请求分配人员，提取SCI，进行修改；

提交修改后的SCI，并测试（或者评审）；重建软件的适当版本；

复审（审计）所有SCI的变化；发布新版本。

---可以通过两种表格来帮助发现受到变更影响的内容，一种是《需求跟踪表》，一种是《配置项依赖关系表》

配置库管理

(1)设置配置库（即文件夹设置）和设置版本的分支

(2)为每个配置项从建立开始就划分成3个不同的分支：私有分支、集成分支、公共（主干）分支
 - 私有分支（开发人员的私有开发空间）：开发人员
 - 集成分支（开发团队的公共空间）：由系统集成员及相关指定人员负责：所有涉及多人协调的开发工作（如集成测试等）都必须工作在这一空间中。该开发团队拥有对该集成分支的读写权限，而其他成员只有只读权限。
 - 公共（主干）分支（整个软件开发组织的公共空间）:系统集成员:各个开发小组在现阶段的任务完成后，将可以发布的版本归并到该分支上,对组织内的全体软件人员开放只读权限
上面定义的3类工作空间（分支）由配置管理员统一管理

(3)按配置项类型分类建库和按任务建库。

(4)配置库的日常工作：对配置库的定期备份；清除无用的文件和版本；检测并改进配置库的性能等

配置审计：主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实实现

记录了谁修改了这个工件，什么时候做的修改，为什么原因做出这个改动，以及修改了哪些地方。 （Who、When、Why、What）

同时配置审计工作该应当说明如下信息：

(1) 变更要求被完成，并且对附加的修改已经执行了 (2) 采用了正确的正式验证手段(3) 遵循了标准的要求 (4) 变更的4W信息被完整记录，并和相关配置项关联

配置审计有两种——PCA、FCA：

PCA (Physics Configuration Audit)-----非配置管理人员
主要是检查版本是否正确一致。(1) 配置项是否齐备；(2) 版本是否齐全，由非配置管理人员来进行。

FCA (Function Configuration Audit) -----CMO
检查配置项是否完整，各种过程文档是否齐备、正确、与需求是否一致，归结为两点，即完全和齐备。

配置审计

When：软件交付或release时；每个阶段结束时；对于维护性项目，周期性地进行
Who：非本项目组成员；其他项目中的配置控制者；内部审计者；SCM小组

配置审计步骤（How-审计流程）

(1) 由项目经理决定何时进行配置审计工作（识别配置审计的时间[PM]
(2) 质量保证组或项目组的配置管理组制定该项目的配置审计人员（指派审计者[QA/Audit Group]）
(3) 项目经理和配置审计员决定审计范围（定义审计范围[PM&Auditors]）
(4) 配置审计员准备配置审计检查单（准备配置审计Checklist[Auditor]）
(5) 配置审计员安排时间审计文档和记录，审计活动可能涉及到：项目范围，配置项的入库(check in)及出库(check out)，评审记录，配置项的变更历史，测试记录，文件的命名，变更请求和版本的编号等（通过评审（Review）、文档记录进行审计[Auditor]）
(6) 配置审计员在审计中发现不一致现象，并作记录（识别不符合项[Auditor]）
(7) 由项目经理负责消除不一致现象（关闭不符合项[PM]）
(8) 配置审计员验证所有发现的不一致现象确已得到解决（验证[Auditor]）

配置状态报告

根据配置项操作的记录来向管理者报告软件开发活动的进展情况

应该是定期进行，并尽量通过CASE工具自动生成，用数据库中的客观数据来真实的反映各配置项的情况。

应着重反映当前基线配置项的状态，以作为对开发进度报告的参照

最佳实践：

统一标识配置项并存入安全的配置管理系统；控制和审计配置项的变更；合理组织配置项；

在项目的里程碑建立相应的基线；记录和跟踪变更请求；过程驱动的软件配置管理；

维护稳定而一致的工作空间；支持并行开发；尽早和持续集成；

确保有能力重现软件的构建过程；把握好工具、流程和人员三者之间的关系；善用模式和反模式；

模式

指导我们如何成功应用前人的实践，避免犯前人犯过的错误，提高SCM的实施成功率。

反模式

在特定情况下不应该采取的策略和方式。

码线(codeline)

源代码文件与组成某个软件组件的其他人工制品（配置项）随着时间而变更的进展过程。

码线包含沿着一条路径发展的各个配置项的每个版本

与码线有关的模式：

主线； 活动开发线； 码线策略； 私用版本； 版本线； 版本预备线； 任务分支4，与工作区有关的模式： 私有工作区；储存库； 私有系统构造； 集成构造； 第三方码线；任务级提； 冒烟测试； 单元测试； 回归测试

主线

问题： 
如何使当前活动码线的数目保持在容易管理的水平，避免项目的版本树长得太宽太密？如何使合并的开销减至最小？
解决方案：
简化分支模型：开发单个产品版本时，在主线上进行开发。分支时，先考虑总体战略，然后再创建分支

分支是组织文件版本和显示版本历史的手段，是隔离变更的强有力机制。
主线既要使码线的并发性达到最大，又要使推迟集成可能造成的问题减至最小

私有工作区

问题： 
如何跟上不断变化的码线并取得进展，而不会为环境变化而分心？
解决方案：
以隔离工作的方法控制变更 (Isolate your work to change control)