配置管理计划 配置审计 配置状态报告 产品发布跟踪表

这个我从今年 2 月份就看到了

都试过了 都是提示'SVN'不是内部或外部命令，也不是可运行的程序或批处理文件

已经设了系统变量，但是没有效果

想在编译时生成日志信息，记录 SVN 的相关信息

在批处理中获取 SVN info,提示不能识别 SVN 这个命令

需要用 SVN 的一些命令

有破解版 因为我的直属领导是研发总监，他想把研发人员的代码规范纳入绩效考核来管理，所以这件工作就落在我头上了。

研发人员推荐我去推行 c++ test 现在正在学习中 希望大家多发表下这方面的经验

以前有参加一个培训，老师是这么解释配置项的概念 有 10 个组件构成一个模块，这 10 个组件只用在这一个模块上，那么这 10 个组件不是配置项，而 1 个模块是配置项 就是说，配置项必须要与其他配置项有关联

很想知道大家对配置项的理解！

我觉得有两点比较重要： 1.让项目组中的每个成员都认识到配置管理的价值，都能够把配置管理人员放到一个正确合适的位置上；（现在配置管理人员的地位太低了，没有权威，虽然这与专业能力有很大关系，但领导的重视与项目组成员的认识也是非常重要的） 2.SCM 策略（希望大家对这块多提见解）。

[b] 每个级别相关的过程域都不能少？[/b] 如果是与公司的业务方面不相符的地方可以去掉

[b] 每个过程域下的具体目标和具体实践是不是在过程中都要做到？ [/b] 是要求都要做到，在评估的时候只允许小部分具体目标与具体实践大部分符合，如果有部分符合的情况可能过级就有问题了（不过，国内目前是什么样的情况，想必大家都很了解了，越来越流于形式了）

[b] 对具体目标和具体实践能进行裁剪吗？ [/b] 在第一条已经回答此问题了。

主要是查看各阶段的实现是否有漏掉、多出功能或者与预期的不符 在概要设计、详细设计、编码、单元测试环节，由项目组研发负责人来填写，配置管理员通过检查这个文档以及依据这个文档经常向研发人员了解项目情况，来达到把控的效果，因为配置管理员不会去读研发人员的代码，实际做起来呢，还是有些被动，如果遇到研发人员忘记或者不愿意告诉你一些情况的时候，可能就需要从多方面去了解项目的实际情况。

嗯 是一个意思，不过在实际操作中，我是把它分成两个表来做了

给大家列两张表就看的比较清楚了

纵向需求跟踪： 需求描述（需求规格说明书） 需求描述（设计说明书） 需求 1：XXXX 需求 1：XXX 需求 2：XXX 需求 2：XXX

横向需求跟踪： 需求描述（需求规格说明竖） 接口 需求 1：XXX 需求接口 1；需求接口 2；…… 需求 2：XXX 需求接口 1；需求接口 2；……

我想纵向跟踪大家应该都很容易理解的，这里主要解释下需求的横向跟踪 项目过程中的需求具有溯源性，首先是定义需求，然后将需求转换为最底层的需求（即技术层面），而横向需求跟踪主要是对编码过程中需求的跟踪管理。

不知道我这样说有没有说清楚呢？

例如设计阶段的需求跟踪矩阵，主要就是来自需求规格说明书与来自软件设计说明书的需求的对应表，通过这个表呢，可以一目了然，在设计阶段是否将所有的需求都考虑进去。 但主要还是用来做变更管理的，如果需求做了变更，可以借助这个表较全面的去跟踪其他阶段受到的影响，避免遗漏 只所以叫矩阵，主要是有横向跟踪和纵向跟踪，但通常我们做的比较多的就是纵向跟踪，需求分析——设计——实现——测试，对这几个阶段的跟踪，横向跟踪则是主要是对各需求之间接口关系的跟踪（用的比较少）。

目前配置管理的部分工作都只是配合协助项目的实施开展，这样多少都会让配置管理工作的开展非常被动，领导对 SCM 的认识对配置管理的工作开展固然重要，但从另一个角度来看，也是对配置管理的挑战，配置管理人员的专业水平怎样。 如果配置管理做的够专业，且经常可以给项目提供有建设性的意见，自然而然会被大家所认可，这时我想领导不重视也没有理由了。

想问 virtuallife,那你觉得公司想在配置管理这块得到怎样的产出呢？

[[i] 本帖最后由 水晶鱼 于 2010-5-10 11:48 编辑 ]

只有当公司开始意识到组件的复用和财富库的搭建的重要性，以及代码与文档的管理已成为项目开发的瓶颈时，才会考虑到投资配置管理吧，但不见得会投入 “大量的人力，物力”。

目前大部分公司的领导都知道配置管理是不可缺少的，但在实际的工作当中却很少有公司能把配置管理这块重视起来，有时候感觉配置管理的岗位就是鸡肋。 在以前公司就曾经反应过这样的问题，但领导给我的答复是要想让公司重视配置管理，首先配置管理这快就要做出成绩，让领导看到！而配置管理最大的成绩就是能让所有的研发成果安全的存档，配合研发项目顺利开展，而这样的结果公司认为是理所应当的，这里就有问题出现了，配置管理如何能做出让大家看得到的成绩呢？

需求跟踪矩阵，主要有设计阶段需求跟踪矩阵、实现阶段需求跟踪、测试阶段的需求跟踪矩阵 需求跟踪矩阵主要是为了更好跟踪各阶段的工作是否按计划的需求去开展的，便于管理。

需求跟踪矩阵的内容其实可以很简单的，只要实现管理跟踪的作用就可以了

我之前的公司使用集成化研发管理平台 RDMS，主要是项目管理的一款软件，包括缺陷管理、变更管理等等 是收费的 不过很好用

个人觉得变更管理是配置管理中很重要的一部分，配置管理员不仅要在变更管理过程中确保变更影响的相关文档内容的完整性和一致性，更重要的是如何将变更的影响进行量化，并能够为今后的项目开发积累有价值的经验。例如这个项目做下来，进行了多少次变更，都有哪些类别的变更，每种变更所占的百分比，变更所影响的模块增删了多少测试用例，平均每个变更影响了多少行代码及增加或减少了多少工作量等等，有很多需要去探究。变更管理做的越深入，项目的风险就能够越早的暴露出来，项目自然也越容易得到控制。

“比如说一个开发过程，过这个过程进行管理的话，是不是就只去管它的输入、输出和活动，就不用管开发过程中的细节东西，只要这个过程产生的额结果能到达我要求的指标就行。”

我觉得这是配置管理要做的最基本，也是最表层上的内容，了解项目开发的过程还是非常有必要的，否则在最后的结项阶段就没有办法深入的挖掘项目的配置管理方面的问题。

举个例子，需求变更管理，这就有可能发生在项目开发中的每个阶段，如何将需求变更管理起来还是有很多要学习的地方

个人觉得，流程就是制定一个规范，让大家做事情有依可循，而过程的管理则提高到了具体实施过程中的效果，也就是如何让项目成为一个成功的案例。