作为一个质量保证经理，我对覆盖了整个开发周期——从早期设计到自动化测试——的若干的产品负责。在产品发布以前，我安排内部客户使用它们以评估产品的完备性。

        在我寻找分析Rational Application Developer的代码和检查工具的内部客户的过程中，我遇到了来自一个令人惊奇的抵抗源：我自己的开发团队。为什么？原因之一是我们的软件的成熟水平。

        在能力成熟模型Capability Maturity Model (CMM)的起源地——卡内基梅隆大学的软件工程学院，研究人员是这样解释这种现象的：“成熟水平是一个详细定义的，在实现一个一致、成熟的软件过程中的成熟状态。” 1 随着你实现成熟框架的每一个级别，你的组织能力提高了。但是很少的软件组织拥有合适的系统化的有效改进项目来推进到下一个成熟水平。

        这篇文章解释了如何使“下一个水平”的实现变得容易一点，提供了向你的开发过程中成功引入自动化工具的要点和技术。

概述：能力成熟模型

        尽管CMM最开始是被美国国防部指定用来帮助限制软件卖主的，目前它已在世界范围内被军事，贸易和政府组织所使用。它已经被证实不仅可以减小与开发项目相关的风险，还能够提高效率和整体产品质量。模型有五个组织成熟等级，如图1所示。

图1：软件过程成熟度的五个等级

        表1说明了五个成熟等级的特点，参照是模型最近的文档CME / SEI-93-TR-24。

表1：成熟等级的特点

        尽管这些概念都很简单，它们的执行却不然。大多数软件组织仍然停留在第一级。不到百分之五的组织在努力达到第四级或第五级。通常，提高一个成熟度等级需要两年半（这指的是你很勤奋并对任务很严格的情况下所需要的时间）。我们失败是因为我们不能摆脱旧的习惯，特别是当时间紧迫的时候。这意味着我们实际上永远也不能经历和体会我们的质量初始情况和过程的全部结果，于是我们不相信那些结果是对的。

工具实施和过程改进

        如果你已经意识到在你的开发周期中的一或多个方面使用自动化工具的需求，并已经评估了你的目标和为你的需要选择了合适的工具，2使用CMM的等级作为指导可以帮助你成功部署工具。

必须记住的三件事情：

1. 工具的设计是为了使过程变得容易；如果你不遵从那个过程，那么工具对你来说是没有价值的。
   
   
2. 时间是敌人。如果看不到工具的价值，人们就不会把他们宝贵的时间投入到学习如何使用这些工具中。
   
   
3. 工具的有效性将与你的组织的过程成熟等级直接成比例。你的成熟等级越高，那个工具的投资回报就越高。

示例：静态分析和检查工具

        正如我前面提到的，尽管我成功地吸引了很多IBM团队使用Rational Application Developer——我们的静态分析和检查工具, 我自己的开发团队却抵制这一工具。他们了解产品，也同意使用它可以带来好处，甚至还同意使用工具。但是，最后，他们从不安排时间来使用它。我着手找出原因，采用了如下的步骤：

1. 确定你想要实现的工具（在本例中，是Rational Application Developer）。3
   
   
2. 确定你的工具支持的过程（对Rational Application Developer来说，过程是代码检查）。
   
   
3. 在附录A的检查过程（或为你自己的目标，工具和技术集合设计一种特殊连接方式）中使用成熟度等级清单来评估你的开发团队的成熟度现状。
   
   
4. 使用相同的清单发现其他使用你的产品的组织的成熟度状况。

        我的发现使我既惊讶又尴尬。和很多软件组织一样，我的团队处于第一级（没有适当的过程），而其它团队有形式上的代码检查。概括来说，他们在检查和评价方面有更为成熟的过程。这就是他们能够立即发现工具将会提供的价值的原因。与之形成对比地，我的团队没有看出为了支持一个团队成员不会首先选择的过程而投入时间，资源和开发周期的价值所在。

        在找出原因以后，我决定把开发精力集中到更为成熟的组织上。我还下决心要在检查和评估方面训练我的开发组织。我想，一旦检查成为常规并遵循一个规则的时间表，我的团队就将会发现Rational Application Developer的价值。尽管如此，在团队成员真正体验到工具的价值和对投资的回报之前，他们将会继续抵抗。

        图2展示了我的发现的时间进程和概况。尽管我在自己的组织内部部署Rational Application Developer上不是100%的成功，这仍是一次很好的学习经历。

图2：时间进度概况