CMM 中的配置管理

CMM中的配置管理
清华同方股份有限公司软件基地
焦阳
在CMM2中共有六个关键过程域，配置管理是这六个之一。

在我们公司没有进行基于CMM过程改进之前，项目组对开发过程中所生成的工作产品较难进行有效的管理，操作的随意性较大。

工作中经常会出现工作产品丢失，工作产品版本不一致，无法恢复到某一个特定版本的工作产品等诸如此类的问题。

有时会影响项目的正常开发，虽然公司也进行了一些对工作产品管理方法的探索，但由于缺乏理论指导，还不能够从根本上解决存在的问题。

因此，尽快建立起完善的配置管理体系是保证有效管理工作产品的需要，也是CMM过程改进活动中一个紧要的任务。

软件配置管理的目的就是要在整个项目的软件生命周期中建立和维护软件项目产品的完整性，一致性（不同阶段工作产品的一致性）和可追溯性（可以将工作产品恢复到以前的某个特定的版本以及对于配置活动的追踪）。

具体的目标包括：
1)要有软件配置管理的活动计划，所选软件工作产品要标识，控制和可得到。

2)对已标识的软件工作产品的修改应该是受控的，软件基线的状态和内容应该定期
通知相关组和相关人员。

通过实施配置管理活动，我们觉得项目组的开发工作能够更加的有序开展，所有工作产品都能够得到有效的管理。

我们所实施的配置管理包括以下一些活动：在整个软件生命周期及时地识别出软件配置（即所选软件工作产品及其描述）；系统地控制对配置的改变；维护配置的完整性、一致性和可追溯性等。

我们实施配置管理活动的第一步是引入了配置管理工具。

通过对几种配置管理工具的比较，我们选择了微软的SourceSafe作为我们过程改进中使用的配置管理工具。

通过对公司的员工培训配置管理工具的使用方法，为进一步实施配置管理工作奠定了基础，使得我们的配置管理工作真正地应用到了实际中。

在选定配置管理工具之后，我们开始着手制定公司级的《配置管理章程》及《配置管理规程》。

章程和规程是一个关键过程域实施好坏的基础，如果规程中的指导有错误的话，即使过程实施的再好也只能是在错误的路上越走越远。

章程是公司一级的配置管理活动的指导，描述了公司在配置管理方面的方针政策。

而配置管理的规程则是详尽的描述配置管理中的每一项活动。

包括了配置管理活动的目的，人员的职责，定义每项活动的输入输出条件。

在规程中我们定义了配置管理活动的流程图，可视化地标识了配置管理的各项活动。

见图：
除此之外，配置管理规程还规定了从制定配置管理计划、日常的配置管理活动、一直到产品的交付发行整个软件生命周期的配置管理活动。

在配置管理规程的附录中，对配置管理活动中使用的表格、模板都进行了说明，并且对使用的方法也进行了说明。

值得一提的是，在制定规程的时候，不可能一次性就做到完美，而是需要通过实践不断的进行修改，认真听取项目开发人员和配置管理员的建议。

通过经常组织对规程的讨论，可以检验所制定的规程在实际应用中是否有效，纠正规程中存在的不足之处，公司对规程的这种修改和维护应该一直持续下去。

随着规程的确立，我们开始按照规程所定义的步骤一步一步的执行。

在执行的过程中，首先要求为每个项目分配至少一名兼职的配置管理员，该配置管理员在项目的早期根据软件需求规格说明书和项目的开发计划制定一个详尽的配置管理计划。

该计划通过评审后，各阶段的配置管理工作都按照这个计划进行。

同时，配置管理员建立配置管理库，以保存开发过程中各个阶段的工作产品，以使之受控。

在实施配置管理的过程中我们也遇到了一些阻力，主要是大部分开发人员已经习惯了过去的那种开发方式。

现在要求他们每天在开发的时候都从配置库里检出代码或文档等工作产品，开发完成时再把它们检入到配置库中，他们认为这种方式没什么必要。

还有的开发人员刚开始没有养成习惯，经常忘记从配置库中检入、检出工作产品，而直接修改本地的工作产品。

对于出现的这些问题，只能通过经常的检查措施，来培养开发人员的工作习惯，规范开发过程的管理。

让开发人员通过一段时间的工作，体验到配置管理给他们带来的好处，这样开发人员才能接受这种新的工作方式。

可以说，在刚开始实施配置管理的时候，我们的问题还是比较多的。

一方面经验欠缺，另一方面实施的时间也很短。

在北京航空航天大学软件工程研究所（北航软件所）为我们公司做的第一次小型评估中，两位专家发现了我们配置管理关键过程域中存在的很多问题。

比如：需求过程没有建立严格的基线管理；配置管理员没有定期向高层经理和项目经理上报配置状态报告；没有定期的进行配置管理审计工作；SQA没有定期的检查配置管理活动等。

此外，由于配置管理工作开始的时间比较短，对配置库的管理不够严格。

小型评估之后，两位专家又针对我们的薄弱环节进行了专门的培训，使我们加深了对CMM中配置管理活动的理解。

在这次评估之后，CMM过程改进进入了一个新的阶段，公司的SCM活动也步入了正轨。

在小型评估之后，我们针对在这次评估中发现的配置管理关键过程域中的问题进行了改进，强调了SCCB（配置控制委员会）对基线管理的作用。

定期发送配置状态报告让相关的人员了解配置项的状态，引入配置管理审计，对工作中的问题实行自我检查。

各个项目组的配置管理员也从中学到了很多的东西，大大地加深了对配置管理工作的认识，同时也加强了基线库的管理。

对很多模板中不合理的地方进行了修改，使之更加适合于实际应用。

通过这一阶段的过程改进，配置管理工作已经初具规模，基本上成为软件开发过程中的一个必不可少的环节。

在项目开发过程中的作用越来越大，项目开发人员也普遍意识到了配置管理工作的作用，能够积极的配合工作。

在2002年的1月份，我们接受了由美国主任评估师Patrick O’Toole为首的评估组所做的预评估，这次预评估是极其严格的。

目的是要找到我们目前还有哪些需要改进的地方，并决定我们能否按照原定计划进行正式的评估。

这次预评估是完全按照正式评估的模式进行的，为了这次预评估我们进行了充分的准备。

在评估中，评估组总结了我们组织中在配置管理方面的优势和不足，优势方面：
项目的配置管理活动进行了计划和管理；
基线的变更由配置管理委员会(SCCB)评审和批准；
使用SourceSafe
员会）的组长都是由项目经理担任的，但是Patrick O’Toole指出SCCB的负责人一般不应该由项目经理担任，因为SCCB组组长的角色有时会与项目经理产生利益上的冲突，在项目开发过程中存在的一些问题可能会难以发现。

预评估结束后，我们将SCCB组组长定义为本负责阶段主要开发任务的代表，这样就能从本阶段及本阶段开发的软件工作产品的利益角度，来进行SCCB的管理活动。

此外，评估组在评估过程中提出我们的变更申请和问题报告缺少跟踪状态。

在跟踪的过程中，SCCB不能清楚地掌握变更处于哪种状态。

预评估结束
后，我们将变更申请和问题报告中的变更过程的跟踪状态定义为：创建、打开、已解决、关闭四种，这样问题跟踪时状态更清晰。

评估过程中，还发现有些项目组成员未能自觉的遵守配置管理计划，进行配置项的检入检出活动。

原因是项目组成员未能习惯性地进行检出检入活动，我们为此不断的进行培训及提醒，这种状况随着配置管理观念的日益深入人心而不断得到了改善。

预评估结束后不久，我们对预评估中发现的问题进行了改进，并对一些模板进行了修改。

比如配置状态报告，早期的版本虽然也能够反映出配置项的状态，但是模板的结构不完善，填写起来比较费力，对此我们采用矩阵式的填写格式，既达到填写方便，又便于阅读。

通过一段时间的努力，我们的配置管理工作终于基本符合了配置管理规程的要求，并在全公司范围内普遍应用，且稳定运行了。

在CMM二级正式评估前的最后准备阶段，我们就开始了积极的准备。

全面的查找章程、规程是否符合标准，是否适合组织的开发过程，发现不符合之处立即进行修改，并通知到相关的人员。

各项目组的配置管理员开始查找配置管理工作中是否还有不足之处存在。

虽然天寒地冻，但我们的工作气氛却十分热烈，工作情绪也是空前的高涨。

不仅维持了正常的开发工作，而且还不断的完善配置管理。

三月末，北航软件所周伯生教授、吴超英老师来帮我们做正式评估前的最后一次调整工作。

在这次检查过程中，配置管理关键过程域无明显问题出现，我们对通过CMM二级正式评估充满了希望和自信。

二零零二年四月二十三日，我们终于迎来了我们盼望已久的CMM二级的正式评估。

ATM组由六人组成，组长为SEI授权的当今最活跃的五名主任评估师之一，美国的主任评估Patrick O’Toole担任。

外部评估员由指导我们进行过程改进的北航的周老师和吴老师，他们对我们的过程改进工作状况十分了解。

内部评估员为我们公司的于波、于景新和李淼。

评估工作从二零零二年四月二十三日至四月三十日，历时八天。

在这八天当中评估工作紧张而有序地进行，我们配置管理组作为一个职能组参加了评估的访谈，访谈过程十分顺利。

随着参加评估的成员自信地进入访谈室、兴奋地走出访谈室，评估结果公布日期也不断的临近，而我们的心也随着越发的紧张，那种对通过二级评估渴求也越发的强烈。

二零零二年四月三十日，真是值得纪念的一天。

在这一天，美国的主任评估师亲自宣布，我们顺利通过了CMM二级评估。

评估师们向我们祝贺我们取得了成绩，我们为自己的努力成果所欢呼，胜利带给人们的喜悦是无限的，每个人都以不同的方式庆祝着我们共同成果。

CMM二级正式通过了，但我们没有因为这种阶段性的成果而感到满足，我们深深地知道过程改进任重而道远，配置管理应该贯穿软件开发过程的始终，我们将继续通过共同的努力，将过程改进工作进行到底。