CM 配置管理 用实例学CMMI V2.0

问: 什么是配置审计，为何分物理审计？功能审计？

答：配置审计可以针对所有配置相关的活动，包括：基线、变更有没有按配置管理的规定做好，以确保没有出现配置相关的问题。例如在发表前，审计所有变更有没有做好，所有测试发现bug的修改有没有测试好，有没有按公司规定在check-in到配置管理系统时写清备注，让别人知道这次变更了什么？

也可以包括所有基线的建立，是否已经评审过，评审发现的问题是否都有改正，才建立基线。物理审计就是针对这些查看有没有一些放错位置，命名不对的问题，功能审计是从这些变更是否可以对应需求的视角来判断。

问：这么多东西要看，做审计不是很费劲、很难做完吗？而且审计员也不一定懂技术，如何判断做得对不对？

答：审计不用判断技术内容，例如你可以依照bug的跟踪表，看bug有没有完整跟踪记录，如果没有就要相关开发组长提供。审计员就是从这些记录来看是否有配置管理的缺陷。

从这个例子，我们看出也需要知道公司基线建立、变更的过程。简单说就是必须通过评审和测试才能建基线，变更管理就是对基线建立后的变更控制，通常要有变更申请、影响分析、经过变更控制委员会（CCB）的批准，如不拒绝，就由配置管理员把要修改的配置项从基线取出来，做完变更后经过测试/评审，确保变更后没错，才更新基线。

配置管理常见问题：

1. 没有控制好变更，导致需求和里面的产出物不断变化、扩大，很难控制，最后导致项目延误

2. 没有基线的概念导致找错文档产出物，影响后面的工作，导致返工

3. 要配置管理的产出物，储存的项目服务器或系统没有定期备份，导致东西丢失

4. 不理解什么是配置审计，虽然公司有配置管理流程以及要求，但实际上没有执行

目录

 

1序

2为什么要做 Configuration Management 配置管理 (CM)

3CMMI 1.3中CM过程域介绍

4CMMI V2.0 , CM 介绍

5CM 1.1 控制版本

6CM 2.1 识别配置项

7CM 2.2 建立配置管理系统

8CM 2.3 创建或发布基线

9CM 2.4 跟踪变更请求,控制配置项

10CM 2.5 建立配置管理记录

11CM 2.6 执行配置审计以维护配置基线、更改和配置管理系统内容的完整性

12如何开展

13反馈

14附件: Git commit 操作例子

15References

序

十多年前，我给一家香港公司做CMMI 3过程改进。过了一段时间，我问他CMMI 3哪方面对他们公司帮助最大，他毫不犹豫地答——配置管理。

想想也是——做产品的公司，如果配置管理做不好，新人来无法投入生产。80年代，当时还没有配置管理系统，十几位开发人员便配一位文档管理员，全职管理编码员的产出物。

下面我们看看CMMI模型 (V2.0)如何帮助我们把公司的配置管理做好。

 

为什么要做 Configuration Management 配置管理 (CM)

为了确保产品的完整性，避免配置管理的问题，导致没找到版本正确的产品，或者用错产出物，导致后面返工。

配置管理基线的概念：从客户需求最终变成产品是经过很多步骤，包括：需求、 设计、 开发 、测试等等，所以每一个步骤都应该评审好或测试好才确保不会有本阶段遗漏的问题出现在最终产品中。因为这会让后面返工，所以每一个阶段的评审或测试后都应该成为一个基线保存好作为下一步工作的基础。基线管理不善会导致后面的工作混乱与返工。配置管理的目的是通过配置项识别、版本控制、变更控制和配置审计来确保产品的完整(integrity)，减少返工。

CMMI 1.3中CM过程域介绍

CMMI V2.0 , CM 介绍

V2.0 对应 V1.3 

• 从以上两个图，大家可以看出之间的对应:

• CM2.1 <= V1.3的SP1.1

• CM2.2 <= V1.3的SP1.2

• CM2.3 <= V1.3的SP1.3

• CM2.4 <= V1.3的SP2.1 + SP2.2

• CM2.5 <= V1.3的SP3.1

• CM2.6 <= V1.3的SP3.2

CM 1.1 控制版本

Perform version control.
GIT实例
把会有变更的代码commit到GIT服务器上，做版本管理。

对不熟识GIT的可看最下面附件例子，了解GIT如何操作。

 

 

CM 2.1 识别配置项

Identify items to be placed under configuration management.

配置标识包括:

• 交付给客户的产品

• 指定的内部工作产品

• 获得的产品

• 工具

例子
配置项可包括:

• 需求规格说明书

• 接口规范

• 建筑规范

• 设计规范

• 代码模块

• 测试计划

• 测试程序

• 项目计划

• 质量计划

• 配置管理计划

• 风险管理计划

• 数据字典

CM 2.2 建立配置管理系统

Develop, keep updated, and use a configuration and change management system.

制定有不同的控制程度：不控制、版本控制、基线等。放在不同的文件夹，包含check-in, check-out的步骤，和备份、恢复、还原等。

GIT实例

配置管理系统，可以很灵活地做分支

比如你是一家做软件产品的公司，会对不同的客户特定要求做分支，随着变化，分支会越复杂越多，到一定的程度。便需要和回主干，这些都是需要公司级来规定。按项目需要，做配置审计，看是否按规定执行。

CM 2.3 创建或发布基线

Develop or release baselines for internal use or for delivery to the customer.

瀑布性项目中，每个阶段形成一基线，作为以后开发的基础，基线可以包括需求、设计、编码、测试等。

GIT实例
因为基线是先通过评审/测试，再作为以后开发的基础，对应打TAG，而非BRANCH。

TAG是静态，不动的； BRANCH 是动态，会不断依据以后的 commit 更改。

 有些用GIT配置管理的团队一直都没有用TAG打标签
 问：为什么不打标签TAG
 答：任何改变的都要记录，随时可以回滚，所以不需要。
 问：你如何可以快速找到某一次通过测试的稳定版本?
 答： ....

 

CM 2.4 跟踪变更请求,控制配置项

Manage changes to the items under configuration management.

变更流程：变更申请-影响分析-识别变更的优先级-由CCB批准。例如代码修改后，必须要通过评审或测试，再允许基线有对应的变化。

但是基线建立以后，可能需要变化，所以我们应该有基线变更的流程。8.5图就是一个传统变更管理的流程。从变更申请开始，要做初步的分析确定大家理解变更率是多少，具体了解需要多少工作量，难度等等。然后变更申请需要经过CCB变更控制委员会去批准。为什么我们说是变更控制委员会，因为不同的变更类型批准人应该不一样的。例如，如果是一个跨产品之间的接口变更，可能要最高的技术总监同意，每个部门领导同意才可以变这个接口，因为影响很广泛。如果有需求变更的话，可能需要有客户代表参加讨论。反过来如果只是一个代码，因为测试bug的发现需要更新，也算是一个变更，但这个审批就可能只是小组长通过，或者甚至不需要审批也可以。所以我们需要预先设好什么类型的申请需要什么人审批。加入变更申请通过后就要交给相关人去修改，改完后，通常要有评审，回归测试，测试好后才交给配置人员，把基线更新，变成一个新的基线。

变更控制委员会(CCB)成员不一定固定，例如：需求变更可能需要客户代表参与评审。反过来，如果是编码需要修改/更新 代码，连项目经理都不需要，只要组长审批通过就可以。

敏捷例子

一个冲刺通常是2-4周，在冲刺时不应该有任何变更，这样可以确保每个冲刺都有充分的测试时间。 反过来，很多瀑布性开发的项目，因前期开发延误，导致最后阶段的测试时间不够。

CM 2.5 建立配置管理记录

Develop, keep updated, and use records describing items under configuration management.

例如，在GIT，有没有规定每次提交的代码的备注要写什么，如果你针对一个bug做了代码修改，有没有在提交代码时，按规定写清备注 （如 BUG号，修改的描述），否则过了一会便没有人记得改过什么，为什么改，可能连自己都忘记。

这里也需要让大家知道当前每个配置项的状态： 如 check-in, check-out 或成为基线，这些信息都可以由配置管理系统来管理。

系统、硬件和软件工程项目的配置管理状态会计(Configuration status accounting)遵循财务会计的概念。想象一下，你到自动柜员机查询你银行账户余额。假设你觉得余额应在2000美元左右。当您查询自动柜员机时发现您的余额只是1000美元，您会想知道发生了什么导致。大多数银行系统都能打印出您过去15天或30天的交易。你便会发现配偶花了1000美元买了一套新的高尔夫球杆，这就是余额没有达到预期的原因。配置管理状态会计以同样的方式运作。

为了支持这一点:

• 配置管理操作必须被记录得足够详细，这样每个配置项的内容和状态都是已知的，所有相关人，特别是项目负责人都应该能够看到。

• 已知的配置状态的基线配置项目，以前的版本应该能够恢复。

• 必须能够清楚地描述基线之间的差异。

• 按需要维护和更新每个配置项的当前状态和历史记录

• 报告必须足够详细，以支持管理需求

• 应定期向相关的组和个人发送标准配置管理状态报告

CM 2.6 执行配置审计以维护配置基线、更改和配置管理系统内容的完整性

Perform configuration audits to maintain the integrity of configuration baselines, changes, and content of he configuration management system.

当我们确实有一些基线的变化，就需要在发布之前做审计，确保所有变更都做好。例如：我们有一套本来是培训课件1.1版本，加了一些中文翻译。在授课后，老师发现3个错误，就去修改，变成新的1.2版本。为了确保那些修改都没错漏，他就找一个独立的人按照那些变化的点去查看那些产物是否正确，这个就是配置审计的概念。确保所有变更都按变更流程做好。所以审计的时候，他本身不需要很熟悉哪个专业，只需要按照变更的步骤查看那些有没有按配置管理的要求去做。配置审计我们有分功能审计和物理审计。简单来讲功能审计就看那些变更是否可以对应上需求，物理审计看查看的时候一些例如存放的位置，命名正不正确，也是从配置管理的视角去看。

审计人员验证变更是否都按配置管理做好 —— 如：是否已通过测试，是否通过评审等。做审计的人不一定是技术专家，只要知道审计要查看什么，要求项目组提供相关的证据。

配置审计

配置审核应回答以下问题:

• 系统是否满足要求?

• 代码/文档显示的状态是否正确，如，已建立?

• 版本已包含了所有更改?

• 版本变更是否已经过批准?

配置审核验证产品是根据需求、标准或合同协议构建的。审计验证所有产品组件都已生成、正确标识和描述，所有更改请求都已解决。基线审核应在阶段结束时进行，以持续确保基线化配置管理系统内容的完整性和正确性是根据项目计划中所述的需求和批准的变更来验证。

审计可通过检查同行评审报告、测试报告、版本描述、发布说明内容和目录、模拟和仿真结果，以及原始文档与其更新版本之间的差异来进行。产品的功能和性能应该与需求进行比较。此外，维护活动(架构规范和设计规范)以及常规使用所依据的文档(用户手册、操作手册、安装手册)应该与需求进行比较。当产品准备好打包和交付时，最终的配置审计通常被称为功能配置审计(FCA)和物理配置审计(PCA)。功能配置审计验证所交付的产品或产品组件是否满足需求以及所有已验证的变更请求，仅此而已。物理配置审计提供系统配置项的独立评估，以确认构成“已构建”系统的每个配置项都正确。进行这些正式的审核是为了验证产品及其文档在内部是一致的，并准备好交付给客户或最终用户。客户交付文档包括安装手册、操作手册、维护手册、版本说明或版本描述。

FCA和PCA是基于基线审计,如下面图8.6：

业内最新动态
银行一直非常重视质量与配置管理。问他们如何做？
有些觉得单靠人工管理工作量太大，无法推广，计划 会利用工具把多种测试环境的参数配置，纳入配置管理检查中，把整个开发过程自动化，减少人手的环节。类似公司采购从人工一层一层审批变成自动化。

如何开展

问: 有没有一个改善过程的规划图，从无到有应该分几步走来实施？例如：先做那些？

答：很好的问题，V2.0 明确说明从零到一是 先做 版本管理 (CM 1.1); 进一步再升到二便要实现 CM2.X。

问: CM2.X 六条中 先做哪些？有什么好建议？

答：我立马想到下面这条CMMI 培训的练习题:

Which CM SPs could have prevented the problem? 哪些CM的SP可以预防下面的问题？

ABC公司刚交付了软件更新给客户，客户想要知道什么地方做了改变，但是ABC公司，因为变更记录不完整，不清楚，无法回应。

是否只是变更管理出问题？
大家想想：是否如果配置管理系统, 配置审计等做好。也可以防止以上的问题。
所以答案是所有二级的SP 都相关。

同样道理，CMMI 把以上SP 都列入成熟度二级，缺一不可。

但核心还是把变更管好 (CM 2.4) ， 其他 CM 2.X 是辅助。

反馈

在发表前，我将文章发给一些客户朋友阅览，收获了一些很好的反馈：

我个人觉得配置管理中，配置项的定义是非常基础和重要的，并且团队成员要达成概念上的一致性。
配置管理的确是产品研发和工程项目实施的基石，配置管理做不好，项目管理就会发生混乱。但配置管理做的过于细致，则会对项目的效率带来消极影响！
一方面通过工具，一方面可能需要对关键配置项进行管理！

                                                                                                                    ——四川银海 研发总经理乔登俭

 

 

附件: Git commit 操作例子

对不熟识GIT的可看以下例子，了解GIT如何操作： 首先看我们识别文件夹里有哪些需要commit,比如一些数据库文档，一些logfile不需要控制版本，这些就不识别。

在commit之前,先看看状态：

就如下面图1.3这样，把工作文件夹中的Python 程序放到GIT的服务器储存。

 

References

Kasse, Tim: Practical Insight into CMMI 2/e
Loeliger, Jon: Version control with Git 2/e
Percival: Test Driven Development with Python 2/e