查看完整版本: 配置管理最注重的东西是什么

个人感觉配置项应该是基础，而真正的核心应该是管理。配置管理不光是关注什么是配置项，而是关注如何控制配置项，控制其版本，其变更，核心应该是对配置项管理的过程，如同之前在另一篇帖子上所说的配置管理是3分配置7分管理一般。所以说配置项是基础，版本管理是核心。。<看了29.34两位兄弟的帖子，发现之前表述有让人误会的地方，删掉前面一句－“变更控制也是针对版本的变更而来的”>

[[i] 本帖最后由 W.ff 于 2007-6-4 17:49 编辑 [/i]]

支持26楼W.ff的看法，我也是这么认为的。^_^

天使

我觉得说的挺对的。又上了一课，的确，版本控制管理真的挺有作用的。

回复 #25 l2002b 的帖子

严重同意！变更管理才是核心。

版本控制虽然占了日常配置管理工作的很大部分，但大家一定要从开发整个生命周期来看配置管理， “变更管理“是贯穿整个生命周期的任务。

回复 #26 W.ff 的帖子

支持W.ff的看法！

qingqing版主描述的也很清楚

看了大家的发言  我有点搞不清配置项和基线有什么区别？
也还是不太明白配置项的概念，我想我应该好好去理解这个词的含义了！
若有个很形象的解释，还是很乐意听到各位大师们的指点的
这个人有点笨——我

回复 #29 河马 的帖子

呵呵，河马兄，我只是把变更管理和版本管理糅合在一起了，“而真正的核心应该是版本管理，[color=red]变更控制也是针对版本的变更而来的[/color]”“[color=Red]核心应该是对配置项管理的过程[/color]”，可能没有表达清楚，实在不好意思。

[[i] 本帖最后由 W.ff 于 2007-6-2 11:54 编辑 [/i]]

核心是变更管理。版本是通过变更产生的。
如果一个软件产品可以只有一个版本就可以交付的话，那么就不需要进行变更和版本的管理了。
版本是结果，而中间的过程才是保证软件质量的重中之重。

版本出现变更，变更产生版本。先有蛋还是先有鸡的问题就不要讨论了，同意最后一句“中间的过程才是保证软件质量的重中之重”。

绝对支持的看法:版本的控制;无论配置项/基线/变更控制等等手段都是为了版本在控制之下

回复 #9 canzheng 的帖子

我也有同感，有时候说不清楚。

回复 #1 canzheng 的帖子

我虽然没有直接从事SCM工作（我负责组织并起草软件工程化方面的相关标准规范），但经过两年的学习对SCM有了一些认识：SCM最重要的作用就是将个人的劳动成果转化为团队的成果，利用SCM工具提高软件的重用，提高工作效率，减少不必要的重复劳动等等。
规定一定的流程是不可缺少的，来实现对对软件版本的控制、软件变更管理等等。

香飘何方的理解让人对软件开发的过程有一定的了解，不愧是对工程化方面有研究的人，但是对于SCM我还是有点稍微不一样的个人理解：

将个人的劳动成果转化为团队的成果这个应该是项目经理关注更多的东西，提高软件的重用这个应该是系统工程师更需要关注的东西，当然我这里不是说只是项目经理或者是系统工程师才需要关注这些东西，作为项目组的成员都需要对这些进行关注，只是大家的侧重点不一样。提高工作效率，减少不必要的重复劳动，对于不同的角色来说有着不同的定义，对于系统架构师来说就是基于构件，可重用，面向对象的体系结构设计，对于项目经理来说可能是资源的利用，进度的安排，而对于SCM来说就是通过版本控制和变更控制来达到此前的目的。

当然上面的只是我个人愚见，而我现在也在学习工程过程方面的知识，还望香飘何方以后多多指教，呵呵。

见笑了！
引用流水先生对SCM的一种解释：“软件配置管理是围绕软件资产的管理。
啥叫软件资产呢，就是设计文档啦，源代码啦，可以跑的程序之类的。
那么，有什么要管理的呢？让我们把它和图书馆的图书管理做个对比。
它们有一些相似点。
首先，图书馆图书管理管的是图书资产，软件配置管理管的是软件资产，它们管的都是信息资产。
其次，图书管理，需要把图书进行分类，以便检索，需要图书存放在合适的地方，以便存取，还要防止虫吃鼠咬。
软件配置管理也类似，需要把软件资产——主要是源代码什么的，放在合适的目录结构里，放在合适的地方存储，防止丢失或者弄乱。
再次，在图书馆，要记录谁借出了哪本书，还没还。
而软件配置管理中也类似，需要记录谁借出了什么文件。
不过，跟图书管理不同的是，软件开发人员借出文件，常常是为了修改它。
软件配置管理要记录谁修改了什么文件，为什么修改，等等。”

这种解释比较符合我对SCM的理解。当然，理解归理解，当真正做的时候太艰难了。

W.FF说“将个人的劳动成果转化为团队的成果这个应该是项目经理关注更多的东西，提高软件的重用这个应该是系统工程师更需要关注的东西，当然我这里不是说只是项目经理或者是系统工程师才需要关注这些东西，作为项目组的成员都需要对这些进行关注，只是大家的侧重点不一样。提高工作效率，减少不必要的重复劳动，对于不同的角色来说有着不同的定义，对于系统架构师来说就是基于构件，可重用，面向对象的体系结构设计，对于项目经理来说可能是资源的利用，进度的安排，而对于SCM来说就是通过版本控制和变更控制来达到此前的目的。”说得没错。SCM贯穿于软件整个生命周期，利用SCM工具给整个项目的每个参与者提供一个可供选择的平台，再将所用的配置项配置管理起来，供后续人员再利用等等。这都是一个SCM管理人员主要做的事情。

这都是个人理解，正确与否尚未确定，本人所在单位是国企，这两年一直在开展软件工程化工作，任务艰巨，路途艰难，也在期待专家指导:loveliness: :loveliness:

其实图书馆的例子只是体现了SCM的配置项标识和变更的审计，这两方面确实体现得比较贴切，但还是有一些重要的东西并没有体现出来，比如说变更控制（可能自己眼拙没有看出来）。

审计是在配置项建立前期还不稳定时采取的措施，此时配置项变化过多，频率过高，所以不需要太大力度的控制变更，不用CCB决定。所以只需要记录变更时间，负责人等信息以便于变更的跟踪。到了建立后期，变化少了，频率降低了，项目组确定整个配置项比较稳定的时候，这个时候就利用基线的概念建立对配置项的管理，这里也是图书馆例子没有体现的。在基线管理的时候，如果发生变更了，就走变更控制流程，由CCB进行商议。

所以我觉得用图书馆管理作为SCM的范例还是不太全面。当然，依旧是个人愚见。
:em3 :em3

回复 #11 rocky_rup 的帖子

这个配置项的准则，::em49:: 不空洞理论，比较实际~~
谢谢斑竹

大家讨论的很激烈阿，觉得图书馆的例子的确与配置管理在某些方面很类似，只是没有包含基线方面的内容。
配置管理工作是非常关注基线的，关注各配置项之间是否保持一致。
另外，我觉得基于活动的配置管理更能体现出配置管理的价值。在某个配置项发生变更的时候，我们总是需要知道该配置为什么要变更以及基于相同原因变更的配置项还有哪些。

配置管理的重点在哪里，要很明白的说真的不太好表达啦，总之配置项是它的重要组成部分吧，不过我做配管有些日子了，居然对配置项的概念还有标识的定义还是有点模糊，真是惭愧哎，大多都是自己一边做一边看资料摸索的，呵

个人比较同意 二楼make 的说法

变更管理最终的落脚点不就是配置项的管理么？

11楼把问题说得很清楚了