UML软件工程组织

 

 

恼人不休的问题:什么是软件配置管理?
 
2008-06-13 来源:scm-flooda.com
 

作为软件配置管理工作者,差不多都有这样的经验:在认识新朋友时,当别人问起自己所从事的职业,自然回答到,“我从事软件配置管理工作”。接着,十有八九,会被问到下一个问题“什么是软件配置管理?”。总被问到相同的问题,倒还称不上是苦恼,真正的苦恼在于回答这个问题,因为软件配置管理真是不太容易说得清……解释了半天,结果往往是,“你这份工作好玄妙啊。隔行如隔山啊,我是搞不懂了。”

是的,软件配置管理,确实不太好解释。软件开发过程中的其它工作,似乎都比它容易理解。开发工程师在编写源代码;测试工程师在测试,挑毛病;需求分析师跟用户确定需求,并且用精确严谨的语言表达出来……虽说这样说未必严谨,但是至少能够得到一个大致的印象。但是,软件配置管理呢?软件配置管理是什么?

下面是软件配置管理的一个权威定义:

“A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements.”

“一套应用技术上和管理上的指导和监督的方法,用来:识别和记录配置项的功能特征和物理特征;控制这些特征的变更;记录和报告变更的处理和执行的状态;以及验证其符合特定的需求。”

如果你看得一头雾水,别担心,这不是你能力上的问题。大部分人和你的感受相同。这个定义,以及类似的权威定义,都高度抽象。用一两句话,确实很难把握好软件配置管理这个概念。需要更多的描述,才能把它说清楚。事实上,这一整本书,就是在认识和理解软件配置管理。而在这一章中,我们将用一些我们相对熟悉的概念来打比方,做对比,来讲解软件配置管理这个概念。通过这样一种方式,让大家对软件配置管理有一个初步的,但比较正确的认识。

1.1. 与图书管理作对比

软件配置管理,是关于软件资产的管理。什么是软件资产呢?源代码,设计文档,可以运行的程序,这些在软件研发过程中产生的有价值的东西,都是软件资产。软件配置管理就是关于这些内容的管理。那么,具体有什么要管理的呢?让我们把它和图书馆的图书管理做个对比。

它们有一些相似点。首先,图书管理管的是图书资产;软件配置管理管的是软件资产。这两种管理,管的都是信息资产。其次,图书管理,需要把图书进行分类,以便检索,需要将图书存放在合适的地方,以便存取,还要防止虫吃鼠咬;而软件配置管理也类似,需要把软件资产——主要是源代码,放在合适的目录结构里,放在合适的地方存储,防止丢失或者弄乱。再次,在图书馆,要记录谁借出了哪本书,还没还。这是为了保证,图书馆的书不会丢失; 而软件配置管理中也类似,需要记录谁“借”出了什么文件,什么时候“还”的。在这一“借”一“还”的过程中,程序员修改了它,而软件配置管理记录下了这些修改。那么,为什么要记录呢?

因为软件资产与图书资产不同,软件资产在不断变化,不断演进。项目初始的时候,可能只有一份简单的项目计划,而项目结束时,已是可以交付给用户的产品。如果缩小视野,单就某个源代码文件来看,也会看到,通常它会在项目的某个时刻,被某个程序员创建第一个版本,然后,可能有不同的程序员,不断修改它,产生新的版本。软件配置管理关心:是不是这个文件的各个历史版本应该被记录,以便今后翻阅?是不是各次修改的修改者、修改的原因应该被记录,以便将来可以理解当时的情形,理解为什么做出这样的改动?更扣人心弦的是,当两个人同时想要修改一个文件的时候,可能会导致其中一个人的改动丢失,也就是常说的版本覆盖。那么,是让他们一个改完了另一个再改呢,还是让他们同时改,在将来合并?等等。

所以说,软件配置管理是关于不断演进的软件资产的管理。

1.2. 为什么称作配置管理?

机器由零部件组成。例如,汽车一般由底盘、发动机、车身和电器设备四大部分组成。其中,汽车底盘一般包括传动系、转向系、制动系和行驶系。传动系主要由离合器、变速器、传动轴和减速器等部件组成。再往下,基本就是零件了。

机器由正确型号的零部件配置而成。每个零件都有型号、编号。零件组成的部件也有。一直到整个机器,一辆汽车。要保证制造出来的机器是正确的,就要保证选取了所有正确型号的零部件。那么,容易想到,应该有某种列表或文档,标明各零部件型号和组成关系,也就是说,标明配置信息。而当配置有变动的时候,要更新这样的列表或文档。并且,这种变动不能随随便便,是否应该先让总工程师批准?是否应该做相应的测试?这些都属于对配置的管理。

从软件配置管理的视角看,软件也是这么配置起来的。往小了说,各个源代码文件的正确版本配置在一起,编译产生了正确的可运行程序。往大了说,若干软件组件的特定版本,配置构成了特定的软件产品。而有些软件组件,可能参与了不止一个软件产品的配置构成。而当某个软件组件参与不止一个软件产品的配置构成的时候,可能是这个软件组件的同一个版本,也可能是不同版本。看,问题有多复杂!不管理怎么行!

软件配置管理,与对机械系统的配置的管理相比,是有一些自己的特点的。主要有两点:第一,软件更容易发生变化,向前演进。一个程序员,修改一个Bug,可能5分钟就搞定了,于是,5分钟前与5分钟后,已经是不同的版本了。更何况,不止一个程序员在工作。如此快速的、众多的变化,如果靠一个书记员手工记录相关信息,那恐怕比较累。所以需要某种自动化的工具,提供这方面的支持。

第二,软件的耦合性更高。当程序员为某个任务改动源代码的时候,经常要改动不止一个文件。在目录结构上,这些文件可能相距遥远。组件/模块间的接口,往往并不像把鼠标线插到USB口上那么简单。某个模块的变化,常会影响到相关模块 。这个特点,使得在软件领域,需要格外关心整体性。要尽可能早的、尽可能频繁的集成,保证产品作为整体,是可运行的。另一方面,一个模块、一个源文件,可能被几个程序员改动:出于不同的目的,改动不同的位置,甚至相同的位置。因此,版本更容易混乱,或相互覆盖。需要软件配置管理工具提供相应支持,提供便利,同时避免出现问题。

1.3. 其它一些比喻

保险柜

软件配置管理为软件开发提供了一个保险柜。保险柜里,存的都是值钱的东西。存进保险柜,是因为怕自己不小心弄丢,或者被偷走。软件资产也一样,甚至比金戒指之类的更值钱。软件资产也会丢失,特别是源代码。比如,一个软件项目完成后,如果没有进行存储/归档等工作,等再过几个月,想基于版本1.0开发版本2.0的时候,可能会发现1.0的源代码找不着了……无奈,只好从头写。这是自己不小心弄丢的情况。软件资产还有可能被窃取或泄漏。虎视眈眈的竞争对手,无孔不入的商业间谍……所以,一定要把软件资产放进类似保险柜的地方。

岩钉

这是来自攀岩者的经验。系上保险绳,每向上攀一小段,就在岩壁上打个岩钉。这样,即使偶尔失手,也不会从半山坠到谷底,只是向下滑一小段。软件开发也是一样,适当的保存历史版本,可以在失手的时候回退到上一个安全的地方。这里的版本,不仅仅指具体某个文件的版本,也指整个产品的版本。不仅指源文件,也包括需求、设计、测试用例……当我们关心软件产品的部署和运行情况时,版本还意味着,某个软件,上次安装的版本是多少?这次升级到哪个版本?如果升级失败,应该回退到上一个版本。

脚印

一步一个脚印。这有两个含义。首先,先走好这一步,踩实了,踩稳了,再走下一步。软件研发也是这样,需要里程碑;需要基线;需要每个迭代结束时,内部或外部的发布。这些是项目的脚印。在每个脚印处,我们要认真检查,是不是踩实踩稳了。这可能是通过相关人员的评审,领导的审批,可能是通过软件测试,也可能是通过某些检查。

其次,一个个的脚印,就构成了足迹。它告诉我们,我们是如何一路走来的,走的是哪条路。必要的时候,我们可能会回顾。还有可能,我们会回到半路,以便从那里再闯一条新路出去。对应到软件开发,我们就是要保存历史上的版本,已备将来的不时之需。

好了好了,据说所有的类比和比喻都是蹩脚的。软件配置管理是什么?软件配置管理就是软件配置管理。如果再多说几句,那就是:它是关于不断演进的软件资产的管理。这涉及到存储和安全;涉及到记录它演进的历史;涉及到让修改和变更井然有序,避免出现版本丢失、版本覆盖等混乱情况;涉及到保证软件代码集成在一起的质量……让我们在随后的章节里,更细致地学习和研究吧!

 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号