CMMI on line

在看本帖之前，请大家先看此帖：什么是配置管理?
http://cmmionline.net/forums/thread/106.aspx

SG1: Baselines of identified work products are established. 建立已识别的工作产品的基线。

配置项与基线的区别：
配置项是需要进行配置管理的最小单位，如：一份文档、一片段代码等。
基线是配置项的一种，基线需要进行更加严格的管理。
一般配置项的管理等级是：权限控制、版本控制。而基线的管理等级除了具备以上管理外，还需要非常严格的变更控制办法。

SP1.1: Identify the configuration items,components,and related work products that will be placed under configuration management.
识别需要放于配置管理系统中的配置项、组件和相关工作产品。

SP1.2: Establish and maintain a configuration management and change management system for controling work products.
中文大意是：建立和维护一个配置管理系统，用于控制工作产品。

SP1.3: Create or release baselines for internal use and for delivery to the customer.
建立和释放基线，用于内部使用或者交付给客户。

做好配置管理工作，首先做好两步：
1)识别需要进行配置管理的东西。
2)建立一个配置管理系统来管理需要进行配置管理的东西。

然后做好两个事情：
1)对一般的配置项进行管理。
2)对基线级别的配置项进行基线级别的管理。

SG2: Changes to work products under configration management and tracked and controlled.
跟踪和控制置于配置管理系统下的工作产品的变更。

SP2.1: Track change requests for the configuration items.
跟踪配置项的变更需求。例如：记录变更的原因、时间、提出人等。

SP2.2: Control changes to the configuration items.
控制配置项的变更。一个配置项发生了变化，与它相关的配置项也会可能需要相应改变，需要跟踪和控制整个过程，直到全部变化结束。

SP2.1 SP2.2 并没有明确指出是针对配置项还是针对基线的，其实两者都使用，不过是针对配置项还是基线，都需要记录变更需求，另外要跟踪和控制变化，只是针对配置项和针对基线，做的程度不太一样而已。

SG3: Integrity of baselines is established and maintained.
建立和维护基线的完整性。什么意思呢？我们看看下面两个SP就知道了。

SP3.1: Establish and maintain records describing configuration items.
建立和维护描述配置项的记录。简单的说，所有的配置管理活动，如变更需求、控制变化的过程、配置项状态等都需要进行必要的记录。

SP3.2: Perform configuration audits to maintain integrity of the configuration baselines.
执行配置审计来维护配置基线的完整性。
什么叫配置审计呢？配置审计分为功能审计和物理审计。
功能审计：指工作产品是否满足一定的功能要求，这个工作一般不由配置管理员负责，而是通过文档的评审、软件的测试进行。
物理审计：就是检查工作产品是否符合格式、版本号等方面的要求，一般有配置管理元负责。
配置项要进入配置库前，都应该经历审计，保证其符合要求，保证后续工作产品的正确性。如果是基线级别的工作产品要进入配置库，需要接受更加严格的审计。

配置管理的学问非常多，欢迎大家提出问题。

 

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

       配置管理的学问真是非常丰富,很多目前是配置管理员的人也不太清楚.很庆幸的是,我们国内很多企业没有QA但是都有CM.原因很简单,大部分公司都用CVS或VSS.

     从CMMI认证来说,配置管理使用工具会带来非常大的便利,而目前配置管理工具也比较多,所以,从这个PA来讲,组织是比较容易做到的.

    从CMMI体系来说，CM其实还是比较复杂及在项目实际执行过程中，做起来还是有一定难度的．

　在组织项目对CM的实践中，缺乏一个综合的解决方案，主要有3点：从功能上涉及如：配置项识别、配置项属性、版本控制、基线建立、变更及变更控制、配置状态表等；从涉及到内容来说：如：需求、代码等；从资源投入上，如：CMO及CCB等。

    总之：没有一个比较好的工具，组织做好配置管理并不容易。

 

 

要做好配置管理，工具却是很重要，向大家介绍一下我们公司用的工具：
1)我们用SharePoint来管理文档。
2)我们用CVS来管理代码(目前我们正在试用Subversion)
3)我们用网络文件夹的方式来管理配置库、产品库。

大家首先要理解好配置管理的原理，然后结合工具，才能把配置管理工作做好。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

  其实配置管理工具可能要我推荐，我个人认为：StarTeam比较好。

   我有点奇怪，想向您请教下：贵公司为什么不采用IBM的工具？？

   我不是卖配置管理工具哦，我说的整体解决方案，其实就是将上面的1和3结合，2独立出来的一个解决方案。不过，张兄他们的足够满足要求。

   但，有一个项目远程管理的问题，采用上述方式可能有点困难。因为，我想项目也就是几种类型：组织本身规划类项目、外包类项目、投标类项目。关键要对三类项目都管好。

   

   

SharePoint是很强的一个平台，配置管理只是其中一个很小的功能，我们基于这个平台做了很多事情：
1)项目管理跟踪
2)资产库平台
3)内部办公系统
4)培训平台
SharePoint最强的地方就是可以订制出很多内容出来，满足很多需要。

另外我们公司基本上是用了微软的全套办公软件、开发软件的，SharePoint、Outlook、Office、Windows Messanger、MSN等软件能非常好的协调工作。

当然，每个公司根据自己情况，选择合适的管理工具。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

对于基线与配置项的区别，我更趋向于这样的说法：“基线是由一组配置项组成的，这些配置项构成了一个相对稳定的逻辑实体。”

个人感觉IBM的工具关键是价格太高，不适合小型公司。一般的公司用VSS或者CVS就好了，而且VSS和CVS的界面比较友好。

另外，请较一个问题。对于个一些维护的项目，因为他没有具体的Work Items,其所有的Work Content只是客户提供的ticket,甚至Ticket都没有，只是phone calls，怎么实施CM？

---

-=P.CHi=-

对于维护的项目，需要进行配置管理的配置项，可能有两类：
1.客户提出来的维护要求
2.项目组的工作产品

对于第一类，一般可能是书面确认的纸张、邮件等，当然也有可能客户的维护要求就是一个电话，对于这种情况要特别注意，是否需要和客户书面确认（可以使纸张的也可以是电子的），可以和客户电话确认后发一个邮件确认要做的事情，另外每次维护活动，特别是上门的维护活动，是不是都需要留下书面的东西，如安装报告、交付确认报告、客户服务单之类的东西。
总的原则就是，我们并不是为了配置管理而进行配置管理的，配置管理是为商业目的服务的，跟客户交往的过程中，那些东西需要书面保留起来，那些东西需要和客户进行正规的确认，怎样做既不会让客户觉得繁琐，同时又让公司所有的工作都有价值，增加以后跟客户“讨价还价”的筹码等等，这些都是需要仔细考虑的。而这些问题，并不是只由配置管理员来想的，更多的是靠项目组、项目经理来思考这些问题的。

对于第二类，维护活动有可能会改一些代码，修改一些参数文件，更新数据库等，这些都应该做好相应的版本管理。这类活动的配置管理工作应该比较容易理解，就不细说了。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

---配置项要进入配置库前，都应该经历审计，保证其符合要求，保证后续工作产品的正确性。如果是基线级别的工作产品要进入配置库，需要接受更加严格的审计。

对这句话我有个疑问，先说说我们的情况。我们的配置库共分了5个区：管理区、开发区、基线区、测试区、发布区。我们是这样设计的，管理区主要放管理文档，如周报、各种计划、审计报告之类；开发区主要放开发阶段的工作制品，如需求文档、设计文档、代码、用户文档等；基线区放建了基线的工作制品；

我的问题是：进入基线区的制品我们有严格的流程控制，可是进入开发区的制品却没有进行检查，完全由开发人员自己控制（我们的配置审计主要是针对基线区），这些进入开发区的制品是不是需要制定流程来控制？比如上面说“......应该经历审计，保证其符合要求”，该怎么操作？

 

“都应该经历审计，保证其符合要求”这句话的含义很广，审计的方式很多，有物理审计、功能审计，有重型的审计，也有轻量型的审计，重型的如需要很多角色来检查，轻量型的如有人走查一下就可以了。

你们针对不同的配置库，采用不同的策略是可以的，也不一定每个区的要求进行“重型”的审计，关键是要合适。

对于开发区中的制品，有需求文档、设计文档、代码、用户文档等，这些文档是否都进行了一些评审？如：需求文档评审、设计文档评审、用户文档评审。
而对于代码比较特别，开发人员每天都写代码，不可能每次都要进行“重型”审计的，代码入库应该是有一定准则的，如我们公司就要求代码必须编译通过才能提交，另外代码需要同行评审，到了一定阶段，就要发版本测试，通过测试的版本需要打上标签，其实这些做法就是代码审计了。

工程类的工作产品，一般由工程组的人员（项目经理、设计人员、编码人员、测试人员）来完成审计就可以了，这是很合理而且也是合适的。

开发类的制品由开发人员自己控制完全没有问题，关键是具体做法是否合适，作为QA来说，只需检查开发人员是否按照要求去做并加以提醒就可以了。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

zhangcb:

SharePoint是很强的一个平台，配置管理只是其中一个很小的功能，我们基于这个平台做了很多事情：
1)项目管理跟踪
2)资产库平台
3)内部办公系统
4)培训平台
SharePoint最强的地方就是可以订制出很多内容出来，满足很多需要。

 

 

我们公司也用sharepoint做文档管理，现在马上实施CMMI，请问如何实现您所说的其它4个方面呢？

SharePoint的很多功能可能还没有发觉出来，不过确实是比较难发掘的，SharePoint本身不提供什么模板。
我们通过项目网站来管理项目，项目网站是定制出来的。
我们通过建立资产库网站来管理资产库，资产库网站也是定制出来的。
我们平时请假、通知、制度、会议等也会做到网站上，这些内容也是定制出来的。
我们的培训课程表、培训评分、培训资料等，也是放到培训网站，培训网站也使定制出来的。
我说的“定制”都是利用SharePoint本身的功能来做的，不需要任何开发工作。

SharePoing的内容比较多，简单说说，以下方面都可以好好发挥的：
1.通知
2.自定义列表：能做课程表、工时申报、需求特性跟踪等等
3.问题列表：能做缺陷管理、问题管理、风险管理等等
4.会议：能做会议记录等
5.讨论：能做一般讨论、在线评审等
6.调查：能做调查、问卷、考试等
7.文档列表：能存放各类文档，不过这个功能不是我们最主要用的，但很多对SharePoint不了解的人士常常会以为这个功能是SharePoint的主要功能。

暂时提供这么多资料，SharePoing的内容实在是太多了，如果需要我考虑专门开培训。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

说白了，就是管理软件工作产品的版本，历史纪录，核查，保障工作产品的可溯性，是吗？类似于公司的资产管理员！

我想问的是，具体怎么做变更管理？

我们现在用的starteam工具，change request这个菜单项也用起来了，但基本上用它来跟踪变更单的各个节点和流程。sccb会议每周也有召开，目的是需求，并确定方案及估计工作量，产品经理指定新需求的变更负责人（履行模块负责人职能）；开发经理承诺提供变更执行人。我觉得都是依照cmmi的流程，执行的挺好的，并不是为了过级做样子。

但是据开发说，在Starteam中，并没有把change request和具体对应的模块，链接起来，可能还是觉得不方便吧，因为有时候一个需求和多个模块有关联。用CC来管理变更，能做到哪个程度？

我的问题是，作为配置管理员，具体应该怎样协助项目组作变更管理，怎样使我的项目的变更管理做到很优秀？

“我的问题是，作为配置管理员，具体应该怎样协助项目组作变更管理，怎样使我的项目的变更管理做到很优秀？”

呵呵，从你这句话，我感觉你至少是态度很优秀！

论坛中还有一些管理配置管理的帖，你先看看？

http://cmmionline.net/forums/thread/1264.aspx
http://cmmionline.net/forums/thread/106.aspx

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

SP1.3: Create or release baselines for internal use and for delivery to the customer.
今天这个实践彻底的让我晕掉了，一直以来，我们理解要创建和发布基线，于是在组织的体系文件中定义了要为配置项打上标签等一系列“创建”基线的活动，然后要求项目组在打好标签以后一定要邮件通知所有干系人，来“发布”基线。但是，对于邮件的必要性，我一直是怀疑的，而且，对于国内一些比较小的项目来说，项目组的成员就那么几个，喊一嗓子就可以做掉的事，还需要发个邮件?这样的邮件一般也会被项目组成员视为垃圾邮件，根本不会阅读，因此，这个活动变成了鸡肋，仔细看了模型要求，居然是create“OR” release，难道我们一直以来都理解错了吗？不一定要用这种形式来release的，也不一定要release的？

楼主能帮忙分析一下吗？“发布”基线是指什么？有没有好的方法实现介绍一下，谢啦!

“发布”基线，我的理解不是说非要有什么正式通知的。按照你们的做法，你们会打好标签，然后大家来取打了这个标签工作产品，这就是“发布”基线的一种做法。

你提到发邮件通知，如果该邮件有实际作用，是需要这样做的，但你又提到“这样的邮件一般也会被项目组成员视为垃圾邮件，根本不会阅读”，对于这点，我要问一下，项目组成员不看这个邮件的话，他们是如何知道应该取哪个标签的工作产品呢？

按照我的猜测，你们打标签时应该会有说明，另外每一个人都可以见到当前有什么标签，会很“自然地”就知道要取那个标签的工作产品。如果你们能做到这话，这样就是你们的“发布”机制，完全没有必要再发个邮件通知来多此一举。

SP1.3主要是针对配置管理的日常工作的，保证各工作产品的正常出入库，保证各工作产品能保持好一致性，能方便地取到正确版本的工作产品。这些工作会很多，根据不同的需要，没有必要全部工作产品都用重型的方式来Release，Release的翻译意思有很多，除了发布，还有释放、给予等等意思，如果我们从发布的意思来理解，很容易认为Release是需要做得比较正式的、重型的。

至于为什么是“Create or release”，为什么是“or”，而不是“and”，之前我还没有留意到这点。我重新看了英文的原文，并没有解释为什么是“or”，我觉得如果没有“Create”，就谈不上“Release”，而“Create”的目的还是为了用，我对“Release”的理解就是用这些基线了，所以我觉得对于一个基线来说肯定是有Create和Release的，所以不清楚为什么用“or”。看看有没有高手能解释一下？

 

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

我来解释下, or在这里的英文中的含义就是表示create和release在此上下文上是等价的含义, 英文中常用这种方式来强调2个类似的说法

论坛很好，拜读了很多您的大作。虽然一直潜水，呵呵！

请问，项目、产品、和实施项目，以及运维项目的配置管理工作上有什么区别对待的？

给点提示吧！。我们是不是应该把产品库分开，建立产品版本的追溯记录，等？

还有，目前的基线没有变更。就是一个周期建一次需求，设计和发布基线。发布基线按代码发布的次数建多条。 我觉得不对，但是想不出更好的方式。

变更控制这一块，你有实例可借鉴吗，我觉得变更控制可以讨论一下。

 

本论坛中配置管理相关的帖不知道你都看了没有吧？
可以到这个地方输入“配置管理”查询一下：
http://cmmionline.net/google.html

配置管理方面的理论和名词特别多，我自己本人并没有系统学过，更加懒得去记这么多名词，我觉得需要对项目工作有一定的体会，再结合学习一些配置管理知识，才能将配置管理工作做好。

项目经理其实是配置管理工作的重要承担者，配置管理员通常是协助的。如果配置管理员对项目工作不理解，对配置管理工作理解过于理论化，会成为项目的负担，相反好的配置管理员，对项目是一大促进作用。

首先要记住，配置管理的目的不是为了配置管理的，不要见到那个文档修改了没有经过什么“变更控制”就大惊小怪，不要见到什么东西没有记录就大动干戈，不要以为全部文档都需要保留历史版本。我见到很多配置管理员，很追求要保留所有文档的历史版本的，这其实是没有不必要浪费成本的事情。

项目、产品、和实施项目，以及运维项目的配置管理工作的配置管理工作并不怎么相同的。要仔细分析这4样东西有什么不同，每种情况会产生什么文档，这些文档之间有什么关系，要设计好配置管理要做到的程度。这4方面说起来内容很多，希望你可以提更具体的问题。

“我们是不是应该把产品库分开，建立产品版本的追溯记录”

这个问题不是很具体，配置管理中有很多某某库、某某库的概念，会把人搞晕，要从工作产品不同使用者的需要来定义你的库，库不要多，适用就行，注意不是所有产品都需要追溯记录的。

所谓变更问题，很多做配置管理的会搞到很大阵仗，小小的文档修改，都要变更控制委员会评审一下。文档写错一个字，要修改，算不算变更？文档有段内容写得不够相信，去修改一下，算不算变更？实际项目开展中，计划文档、需求文档、设计文档、代码等都需要持续细化和优化的，对于这些情况，非要来个重型的变更控制不可？这样大家就会难得去改计划文档、需求文档、设计文档，搞到计划与实际不对应，需求、设计与实际不对应。需要认真思考怎样的变更，需要怎样程度的控制。

对于这些问题，如果还不能想清楚，那就叫项目组一起来定应该如何做，考虑时，不要硬套配置管理的理论。先做起来，慢慢思考和体会，注意，一定要适用，实践出真理，而不是用不理解的理论来硬套实际工作。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

你好！感谢你的回复。

 配置库理论上是分三个区，个人开发区，受控区和发布区。现在公司都是在一个库里，用标签来打基线。

这样就意味着基线配置项没有受控。怎么办？你们公司是怎么做的？ 是不是 物理上用两个库来存放才能解决受控的问题，（或建分支视图）我们用starteam

还有变更的问题。小小的文档修改，写错了字，算变更吗，我觉得不算，但是要修改，涉及到修改基线的话，怎么处理呢。类似于此的琐屑变更，不管吗， 累计多了，一次修改？ 这样，强制要求大家看到有问题的文档而不去修改？ 不知道贵公司怎么做的,?

不是不想好好做事，而是很迷茫，找不到好的做事方法？

我常常想，cmmi的理论是不是太抽象了，教导出许多教条主义战士，不知道该如何去做正确的事情了，