关于软件配置管理 软件测试
一、软件配置管理的基本概念
在配置管理中有几个常用的基本概念是需要弄清楚它们之间的联系和区别的。这些概念是配置项、里程碑、基线、受控库、基线库、产品库等。
软件配置项是软件生存期内，能相对独立开发的一个程序实体或文档。
里程碑即通常所说的软件开发过程中的“阶段”，如果说它们之间有 区别的话，那么“阶段”强调的是过程，而“里程碑”则强调过程的终点和终点的标识。这些阶段可以是需求分析阶段、概要设计阶段、详细设计阶段等等。
基线 是软件开发过程中最重要的里程碑，不过基线更强调的是一个开发阶段到达里程碑时的结果及其内容，如功能基线是 经过评审和批准的需求规格说明书；产品基线是经集成和确认测试后，经正式审批可交付客户的软件产品的全部配置项（包括软件实体和所有的文档）。 [Page]
正如清华大学郑仁杰教授所说 在一个开发阶段结束后，要对相应的配 置项进行基线化并形成各类基线。基线就是一个配置项（或一组配置项）在其生命期的不同阶段完成时，通过评审而进入受控状态的一组文档和程序实体，这个过程被称为 “基线化”。每个基线都是其下一步开发的基点和参考 点；它们都将接受配置管理的严格控制。因此，基线必须通过评审过程建立；基线存在于基线库中，接受更高权限的控制；基线是进一步开发和修改的基准和出发点。
受控库 是软件开发过程中，其修改权限受到控制的文档库和程序库，其中基线库和产品库，特别是产品库的修改权限将受到严格的控制，即使是授权修改的人，在修改前还必须得到批准。
基线库 是受控库中一些特别重要的库，如需求（基线）库和产品（基线）库。
产品库 是存放软件最终产品（即产品基线）的库，基于它的重要性，对它的修改将受到特别的控制。 产品基线是最初批准的产品配置标识。
二、软件配置管理计划
预则立，不预则废”，软件配置管理计划对于配置管理实施的重要性毋庸多言。大家想看看别人做的配置管理计划或者模板，无非是想学学别人的成功经验，避免自己走一些弯路。
但是我想，在这方面，更应该学习的应该是计划软件配置管理实施的思路，毕竟，各个开发团队不同的地方太多了。下面是我观察和思考的一些成果，和大家分享。
像你的老板一样思考
作为一个配置管理实施的执行人员，你怎么样才能够保证这项活动的成功呢？
说起来很简单、但是也是最重要的第一步，就是定义“成功”。
很多负责配置管理实施的人员都是技术人员出身，我经常能在他们身上观察到的一种现象就是：出于对技术的热爱，他们希望把软件配置管理学习、理解得很透彻，然后同样出于对技术的热情，希望能把所有在技术上很“诱人”的东西都实践起来。
我绝对没有贬低这种热情的意思（事实上，我自己也经常被这种热情所导引）；但是，我们一定要小心地提防这种热情把我们引离了通向成功的方向。
为什么要实施软件配置管理？因为有效的配置管理可以帮助我们提高软件产品质量、提高开发团队工作效率。
什么是“成功”的配置管理实施？很简单，只要比较配置管理实施活动前后，软件产品的质量是不是得到了提高、开发团队是不是能够工作在一个有助于提高整体工作效率的配置管理平台上。
软件配置管理活动在整个开发活动中是一项支持性、保障性的工作，它本身并不直接为企业产出可以直接赢利的工作成果；而配置管理每一项活动都需要消耗企业的人力资源，有些还需要购置专门的工具来支持活动的进行，这些都会导致企业生产成本的增加。
所以，在我们计划实施配置管理时要做哪些事情的时候，要小心地界定每一项活动，取舍的标准就是：从事这项活动是不是真正有助于我们实施活动的成功？它对于提高我们产品的质量有多大的帮助？能否帮助开发团队更高效率地工作？
大多数情况下，你的老板花钱让你来做配置管理，并不是来让你学习配置管理或者研究配置管理，而是希望你的工作能帮助他改变些什么；他的投资成功与否，是用投资回报率（ROI，return-on-investment）来衡量，而不是你对于配置管理技术研究的程度。
评估开发团队当前配置管理现状
计划配置管理实施的基础，是搞清楚开发团队当前配置管理的现状。知道自己现在站在哪里，才明白自己下一步要往哪里走。
对于配置管理现状的评估，可以自己进行，也可以引入外部专业咨询人员来完成评估活动。 [Page]
自己进行评估的话，可以参照SW-CMM中关于软件配置管理这个关键过程域的资料；也可以利用PMT编写的《软件组织配置管理能力自我评估问题集》，来完成自我评估的工作。
引入外部专业咨询人员进行评估有两个好处，一是通常这样的咨询人员有比较丰富的配置管理实施经验，评估工作可以进行得更加细致，而且通常咨询人员会在评估结果的基础上提出实施的建议；二是引入外部人员，通常评估结果会比内部自我评估更客观。坏处是要花钱，而且如果该咨询人员与具体的配置管理工具厂商有利益关系的时候，也可能会出现评估过程受到这种利益关系影响的情形。
不管以何种方式进行，评估这个步骤的工作是一定要仔细进行的。有了评估的结果，才谈得上改进。做好这个工作，比到处去找一份配置管理计划的模板更有意义。
定义实施的范围
对于没有正式实施过软件配置管理的开发团队来说，在配置管理方面存在的问题可能会比较多；经过评估，会找出来很多需要改进的点，那么，怎么样来计划改进的工作步骤呢？
曾经有一位朋友向我展示他撰写的软件配置管理计划，从基本的版本控制、基线管理、变更管理，到软件构建的管理（Build Management）、配置审核（Auditing）、配置状态的报告，洋洋洒洒，什么都做在计划里了。他的团队以前没有太多配置管理的概念，因而也出现了很多一直困扰他的问题，在我向他介绍配置管理可以帮助他改善或解决这些问题以后他变成了一个配置管理技术的爱好者。我想他一定仔细研读了RUP配置管理工作流、IEEE软件配置管理标准之类的资料然后写出了这份计划。我对他的计划提了一个问题：“你觉得按照日程安排我们做得完这么多事情吗？”
这就是前边说过的，热爱技术的朋友最容易出现的情况，为技术而技术、为流程而流程；我记得一位朋友跟我说过一句非常有意义的话：流程改进应该是以结果为导向的（Result Oriented）。配置管理的实施也是如此，应当在当前评估的基础上，抓住团队最头疼的几个问题，努力想办法解决这些问题。
大家都知道管理学里有一个黄金法则：80/20法则。在这里我们也可以套用一下，想一想：我如何才能找出20％的问题，在当前这个阶段，这20％的问题给我的团队带来80％的困扰和痛苦，然后，我们集中80％的精力来解决这些问题。
一句话，不要企图一口吃个胖子。流程改进是一个持续的历程，一个阶段会有一个阶段改进的重点，抓住重点、做出成绩，才是有效的改进之道。
计划资源要素
俗话说，兵马未动，粮草先行。配置管理的实施需要消耗一定的资源，在这个方面一定要预先规划。
具体来说，配置管理实施主要需要两方面的资源要素：一是人力资源，二是工具。下面分别论述。 [Page]
人力方面，因为配置管理是一个贯穿整个软件生命周期的基础支持性活动，所以配置管理会涉及到团队中比较多的人员角色。比如，项目经理、配置管理员、开发人员、测试人员、集成人员、维护人员等。但是，工作在一个良好的配置管理平台上并不需要开发人员、测试人员等角色了解太多的配置管理知识，所以，配置管理实施的主要人力资源会是集中在配置管理员上。
配置管理员是一个比较奇妙的角色，对于一个实施了配置管理、建立了配置管理工作平台的团队来说，他是非常重要的，整个开发团队的工作成果都在他的掌管之下，他负责管理和维护的配置管理系统如果出现问题的话，轻则影响团队其他成员的工作效率，重则可能出现丢失工作成果、发布错误版本等严重的后果。然而，由于传统不了解配置管理重要性的原因，在国内的开发团队中，通常大家都不愿意去做配置管理员。我遇到很多情况，都是项目经理找来找去，选出来一个不喜欢做开发工作的女孩，来担任配置管理员。
在国外一些比较成熟的开发组织中，配置管理员被称为CMO（Configuration Management Officer），或者是配置经理；他们被称为是项目经理的左手。从这两个称谓我们可以看出他们对于配置管理员的重视。在选拔配置管理员的时候，也有相当高的要求，比如，有一定的开发经验，对于系统（操作系统、网络、数据库等方面）比较熟悉，掌握一定的解决问题（trouble shooting）的技巧，在个人性格上，要求比较稳重、细心。
在配置管理员这个资源配置方面，要注意后备资源（Backup）的培养。在大家越来越重视配置管理的大环境下，经验丰富的配置管理员会成为抢手的人才；而配置管理员的离开可能会给团队的工作进度带来一定的影响，所以聪明的管理者会为自己留好备份。
选择什么样的配置管理工具，一直是大家关注的热点问题。确实，与其他的一些软件工程活动不一样，配置管理工作更强调工具的支持；缺乏良好的配置管理工具的话，要做好配置管理的实施会非常困难。
具体来说，我想在配置管理工具的选型上，可以综合考虑下边的一些因素。
首先是经费。市场上现有的商业配置管理工具，大多价格不菲。到底是选用开放源代码的自由软件、还是采购商业软件，如果采购商业软件的话，选择哪个档次的软件，这些问题的答案，取决于你能从老板那儿拿到多少钱。
一般来说，如果经费充裕的话，采购商业的配置管理工具会让实施过程更顺利一些，商业工具的操作界面通常更方便一些，与流行的集成开发环境（IDE）通常也会有比较好的集成，实施过程中出现与工具相关的问题也可以找厂商解决。
如果经费有限的话呢，就不妨采用自由软件，如CVS之类的工具。其实无论在稳定性还是在功能方面，CVS的口碑都非常好，我看到过很多组织成功地在CVS上完成配置管理的工作。如果你（或者你的配置管理员）不是一个依赖性很强的人，喜欢自己钻研、自己去寻找资料解决问题，CVS会是一个不错的选择。 [Page]
如果准备选择商业配置管理工具，就应当重点考虑下面几个因素。
（一）、工具的市场占有率。大家都选择的东西通常会是比较好的东西。而且市场占有率高也通常表明该企业经营状况会好一些，被人收购或者倒闭的可能性小一点。
（二）、工具本身的特性，如稳定性、易用性、安全性、扩展能力等。你应当在投资以前仔细地对工具进行试用和评估。这儿比较容易忽略的是工具的扩展能力（Scalability），你现在可能只是在几个人、十几个人的团队中部署这个工具，但是以后可能会有几十个、几百个人要在依赖这个工具建立的平台上工作，到时候这个工具能不能提供这样的支持能力？如果到时候要换一个工具的话，你一定会后悔今天的选择。
（三）、厂商支持能力。工具使用过程中一定会出现这样那样的问题，有些是因为你使用不当引起的，有些则是工具本身的毛病。这样的问题会影响到开发团队的工作进度，你一定希望能随时找到厂商的专业技术人员帮助你解决这些问题。
配置管理工具不是用一次两次的工具，因此，选择配置管理工具其实是选择和哪个厂商来建立一种长期的关系；如果你不信任或者干脆就是不喜欢这个厂商的技术代表，那么，不管他把他的东西吹得怎么个天花乱坠，还是赶紧让他走吧。
三、配置管理变更的关键路径的方法
配置管理来源于硬件系统。例如PC行业中，每一台PC由主机和显示器等构成，而主机又由CPU、主板等构成，对这些构件配置情况进行管理，就是硬件的配置管理。在软件行业，计算机软件由编译后的代码和相关的一系列文档组成。但构成软件的部件的变化是跟随软件产品的开发周期而不断变化的。就频率和程度来说，软件的变化远远大于硬件。因此，软件配置管理是一套管理软件开发和软件维护的方法和规则，其最终体现的是维护软件产品的一致性和完整性。
变更常有
笔者所在银行科技部已经建立了比较完善的项目管理体系和质量保障体系，但要应对分行或支行需求变更和相关软件版本配置管理的问题，如果没有一整套的解决措施和工具的支持，就会出现以下问题：
1)分行反映的缺陷更改不能快速响应，不能快速分配缺陷到指定的开发人员，只能依靠口头或文档的传输，缺乏一个整合开发商服务人员、产品经理(或项目经理)、开发团队领导、开发人员、分行领导的信息传递和交流的平台。
2)分行的需求变更不能快速响应。分行的需求变更和软件版本配置只能依靠手工备份，因而，自身不能快速有效地管理各系统的版本，缺乏版本基线的管理策略。
针对以上问题，可以考虑采用软件配置管理这一关键域的思路系统地解决以上问题。配置管理是整个集成软件项目正常运作的一个管理支撑平台，其目的就是将有关该项目的客户、客户服务人员、产品经理(或项目经理)、开发团队领导、开发人员、高层领导等项目干系人的工作协同起来，实现高效的沟通，及时地共享工作成果。
配置管理的基本功能包括配置标识、变更控制、配置状态发布和配置审计。变更控制是配置管理的重要内容，其目的是为了在动态中保证配置项的完整性、一致性和可回溯性，保证配置项的变更过程规范、受控、有完整记录，受影响的各方均能及时了解情况，并协调一致。
控制不可少
变更控制是通过创建产品基线，在产品的整个生存周期中控制它的发布和变更。配置控制指在配置项标识正式确定之后，对配置项特别是对已提交的代码、相关文档和数据等的变更进行系统地跟踪和控制的过程，主要包括变更的提出、确定配置项的控制等级、变更的评价、变更的处置、实施经批准的变更、对变更进行验证和结束变更。变更控制的目的是建立一套控制软件修改的机制，保证生产符合质量标准的软件和保证每个版本的软件包含所有必需的元素及工作在同一版本中的各元素中可以正常工作，以确定在变更控制过程中控制什么，如何控制，谁控制变更、何时接收变更、批准和检验。
配置项级别
1)已基线化的配置项是指已完成该配置项的审核和批准，并且成为创建或修改其他配置项的输入。例如：一个设计文档已审核、通过、签发，并且成为编码活动的基础。
2)受管理和受控的配置项是指已提交审核，但还没有批准通过的配置项。例如：一个正在进行审核的设计文档。
3)受控的配置项指已置于版本控制，但项目组不能直接进行改动的配置项。例如：用户提供的软件、购买的工具、产品标准等等。
变更请求的状态
软件变更、软件优化和软件bug都是产生变更的原因。变更申请人(用户或产品经理)提出变更时，首先要对受控的配置项的修改提出一个变更请求，说明对软件变更的需求。这是因为变更控制过程是通过变更请求的流动来实现的，而且对软件的任何请求都必须和相应的变更请求对应。
变更请求的状态包括：
1)提交：变更请求提交给配置管理员；
2)拒绝：变更控制委员会拒绝变更请求；
3)接受：变更控制委员会接受变更请求；
4)挂起：变更请求被挂起，以后再作决定； [Page]
5)已验证：更改已执行和验证；
6)关闭：验证并归档配置项，更新的配置项提交给用户(例如：通过版本发布)。
变更请求的类型
1)增强型：变更请求要求对已批准的项目功能进行增强。
2)改进型：变更请求不会造成功能更改，但使配置项的维护更加有效率。
3)纠错型：变更请求对错误进行修正(诸如bug)。
变更请求的优先级
在评价变更请求的优先级时，要对请求变更的配置项进行系统的分析，确定变更影响范围和修改的程度，确定变更的级别，为确定是否有必要记录变更提供参考依据。变更请求的优先级可分为三类：
1)高：严重地影响一些用户或许多用户。
2)中：对用户造成不方便，或是可以采取相应的变通方法处理的主要问题。
3)低：小问题。
修改完后签入（Check in）
对变更的处理，要按照变更控制规程，将变更请求及其相关附件提交软件配置控制委员会审批。配置管理组根据审批意见处理变更请求。
只有配置管理员具有Check in权限。在进行Check in之前，确认下面的事项：
1)所有对配置项所做的修改被批准；
2)所有的更改都经过审核或验证；
3)所对应的变更请求已经被保存起来；
4)所有相关的审核记录被保存；
5)Check in时须注明Check in原因，如对应的变更请求。
从数据库中签出（Check out）
1)对于文档，配置管理员在更改审批人同意后，从配置库中Check out配置项，发给项目组成员修改。
2)Check out时须注明Check out原因，如将要修改的问题。
3) 配置管理员一定要在配置状态发布中跟踪被Check out出来的配置项。
文章来源于领测软件测试网 https://www.ltesting.net/
