似水流年

软件质量保证是CMM(I)的可重复级的定义的数个关键过程域之一。根据CMM(I)中的描述，软件质量保证的目的是向管理者提供对软件项目正在使用的过程和正在开发的产品的适当可视性。软件质量保证包括评审和审计软件产品和活动，以验证他们是否符合使用的规程和标准，还包括向软件项目和其他的有关的管理者提供评审和审计的结果。CMM(I)列出了为了满足这个关键过程与的要求所需达到的4个目标:目标1：软

世界上有很多组织都在进行过程改进，可能是基于CMMI，可能是基于ISO，也可能是组织内部的专项改进工作，但是可以肯定的说，这些改进工作中，取得让人满意成果的并不多，这是为什么呢？过程改进并非孤立的事情，过程改进项目负责人不可能抛开其他的相关人员孤立行动，在平衡时间、成本、质量的过程中也要考虑组织管理者的满意度，并且相对于软件开发项目，过程改进项目显然麻烦的多。根据很多组织过程改进活动的经验和教

相对于配置管理来说，组织级配置管理缺少曝光度，事实上，配置管理包括组织级配置管理和项目级配置管理，我们通常所说的配置管理都是指项目级配置管理。那么，组织级配置管理和项目级配置管理有什么相同和不同之处呢？ 组织级配置管理和项目级配置管理都遵循配置管理的概念、方法、规则、活动。关于配置管理的概念、方法、规则，请参加笔者之前的文章：《配置管理漫漫谈之SCM基本知识》《配置

作为一家IT相关组织，无论规模大小基本上都要求在项目结束后甚至进行中进行项目总结，但是很多组织是否没有意识到项目总结的意义所在？很多人肯定说，项目总结不就是为了可以让其他项目借鉴该项目的经验教训以便以后不发生类似的失误和更好的工作嘛，的确如此，可是有多少组织做到了这一点呢？笔者日前看到了同一家公司同一个部门的两份项目总结报告，报告时间分别为2008年9月份和2009年12月份，却发现其中的内容

 自从CMMI项目启动以来，基于CMMI的集成化过程改进策略已经在很多组织中取得了比较成功的实施，但是不能不提的是过程改进失败的案例数量要远远多于成功案例的数量，也有很多组织开展CMMI项目仅仅为了政治或者商业上的考虑，一旦通过评估过程改进的成果就被抛到一边，这样的过程改进也实在是算不得成功。在过程改进过程中，组织往往会经历以下五个阶段：1、完全没有过程2、已有过程，但是过程不完善

日前，一位朋友向我诉苦说对方公司的模板总是用不好，很多人填写的不正确，不得不每次进行纠正，好奇之下，我像朋友要了对方所说的模板相关文件，朋友仅仅发了一份详细设计说明书的模板，再无它物，我草草看了一下后只好说：“你们的模板用不好是有情可原的，给我我也用不好啊”，对方问：“为什么呢？”，我说：“这是因为你们在定义模板的时候，没有考虑全模板的三部分啊”，模板不就是模板吗？什么是模板的三部分呢？且听在下慢

在我们的过程改进工作中，一个重要的活动就是根据过程使用者提出的问题/建议对过程进行改进。但是在实际操作中，往往针对表面现象/问题做出反应、进行改进，实际上却没有达到改进的目的。这种现象的根本原因在于接到问题/建议时没有注意分析问题/建议背后的根本原因，导致“治标不治本”的现象出现。鉴于很多人不清楚问题分析的步骤，笔者将自己实际工作经验中的问题分析方法分享给大家。 1、在问题定义上达成共识所谓的问题分析，就是理解真实世界中的问题和用户需求并提出满足这些多方面的解决方案的过程。因此第一步显然是把问题拿出来，并且