来自 Rational Edge：为了在软件开发业中更具竞争力，商业机构需要迅速发布高质量软件以适应变化的市场和技术。尽管自动化工具能够帮助完成这项任务，多数组织仍然依靠敬业的团队的巨大努力来获得成功。这篇文章解释了一种通过有效地使用自动化工具突破这种低效的模型的方式。 作为一个质量保证经理，我对覆盖了整个开发周期——从早期设计到自动化测试——的若干的产品负责。在产品发布以前，我安排内部客户使用它们以评估产品的完备性。 在我寻找分析Rational Application Developer的代码和检查工具的内部客户的过程中，我遇到了来自一个令人惊奇的抵抗源：我自己的开发团队。为什么？原因之一是我们的软件的成熟水平。 在能力成熟模型Capability Maturity Model (CMM)的起源地——卡内基梅隆大学的软件工程学院，研究人员是这样解释这种现象的：“成熟水平是一个详细定义的，在实现一个一致、成熟的软件过程中的成熟状态。” 1 随着你实现成熟框架的每一个级别，你的组织能力提高了。但是很少的软件组织拥有合适的系统化的有效改进项目来推进到下一个成熟水平。 这篇文章解释了如何使“下一个水平”的实现变得容易一点，提供了向你的开发过程中成功引入自动化工具的要点和技术。 概述：能力成熟模型尽管CMM最开始是被美国国防部指定用来帮助限制软件卖主的，目前它已在世界范围内被军事，贸易和政府组织所使用。它已经被证实不仅可以减小与开发项目相关的风险，还能够提高效率和整体产品质量。模型有五个组织成熟等级，如图1所示。 
图1：软件过程成熟度的五个等级 表1说明了五个成熟等级的特点，参照是模型最近的文档CME / SEI-93-TR-24。 表1：成熟等级的特点
尽管这些概念都很简单，它们的执行却不然。大多数软件组织仍然停留在第一级。不到百分之五的组织在努力达到第四级或第五级。通常，提高一个成熟度等级需要两年半（这指的是你很勤奋并对任务很严格的情况下所需要的时间）。我们失败是因为我们不能摆脱旧的习惯，特别是当时间紧迫的时候。这意味着我们实际上永远也不能经历和体会我们的质量初始情况和过程的全部结果，于是我们不相信那些结果是对的。 工具实施和过程改进如果你已经意识到在你的开发周期中的一或多个方面使用自动化工具的需求，并已经评估了你的目标和为你的需要选择了合适的工具， 2 使用CMM的等级作为指导可以帮助你成功部署工具。 必须记住的三件事情：
正如我前面提到的，尽管我成功地吸引了很多IBM团队使用Rational Application Developer——我们的静态分析和检查工具, 我自己的开发团队却抵制这一工具。他们了解产品，也同意使用它可以带来好处，甚至还同意使用工具。但是，最后，他们从不安排时间来使用它。我着手找出原因，采用了如下的步骤：
我的发现使我既惊讶又尴尬。和很多软件组织一样，我的团队处于第一级（没有适当的过程），而其它团队有形式上的代码检查。概括来说，他们在检查和评价方面有更为成熟的过程。这就是他们能够立即发现工具将会提供的价值的原因。与之形成对比地，我的团队没有看出为了支持一个团队成员不会首先选择的过程而投入时间，资源和开发周期的价值所在。 在找出原因以后，我决定把开发精力集中到更为成熟的组织上。我还下决心要在检查和评估方面训练我的开发组织。我想，一旦检查成为常规并遵循一个规则的时间表，我的团队就将会发现Rational Application Developer的价值。尽管如此，在团队成员真正体验到工具的价值和对投资的回报之前，他们将会继续抵抗。 图2展示了我的发现的时间进程和概况。尽管我在自己的组织内部部署Rational Application Developer上不是100%的成功，这仍是一次很好的学习经历。 
图2：时间进度概况 Rational Application Developer在开发周期的开始阶段是最有用的，因此让我们看看你主要在开发周期最后应用的工具是如何提高过程的成熟度的。这将指出这些概念实际上是多么通用。 为了证明我的观点，我为测试过程建立了近似于待检查的模型的一个成熟度模型（见附录B：测试过程的成熟度模型）。 当你的步骤需要多次重复时，自动化工具是最有效的。但是在初始级别，没有可重复性。你的测试是特别的，没有任何记录，也没有任何东西需要自动化。 在第2级，当你把你的测试步骤和环境写入文档时，你有了你可以自动化的基线。随着你在成熟度谱上的推进，达到第三级，你继续在开发和测试团队中介绍详细定义的标准。这使得你能够创建一个开发，发布工程和测试都可以使用的自动化测试基础设施。由于更多人正在从中受益，你将从自动化中获得更多价值。 如果你一直运行你的自动化测试，你将获得关于测试时间的数据，产生的典型问题，以及影响你的效率的因素等方面的信息。这是你能够进入到第四级，你将可以更好地管理你的测试时间表和错误率——甚至可以预报发布时间。 在第五级，你进行的是最优化。你可以把其他应用链接到你的自动化测试基础和测试框架上。你还可以结合一些应用，它们可以自动跟踪代码的变化，跟踪测试覆盖，提交错误，检查代码外形和存储使用，等等。在这一级上，你组织中的更多人可以获得更多特性的更大好处并实现更多目标。换句话说，你的成熟等级越高，你将发现更多人利用工具的优势。而他们使用工具越多，他们进入下一个成熟等级就更容易。 无论你处于哪个等级，你可以建立一个协作的和连续不断的改进环境——一种工具和过程成熟度等级间的最优关系。（如果需要关于如何更快推进成熟度等级的建议，请参看附录C）。 确定“第一项任务”工具实施中的一个重要因素是决定在何处引入它：能够展示工具的全部能力和价值的最佳“第一项任务”是什么呢？我开发了一种技术来帮助你回答这个问题。 作为一个例子，让我们再回到测试自动化工具。向自动化的实现投资并不便宜，而且你需要一定的头脑和技术来取得成功。这就是为你的自动化工具认真选择合适的“任务”的重要性所在。我用来决定引入新的工具的时机的步骤如下：
为了进一步说明，让我们按照上述六个步骤引入自动化测试工具。首先，下面是一个好的测试的标准（这不是一个无遗漏的列表，仅是一个示例）。
一旦你理解了这些好的自动化测试的大体标准，你就可以创建更为具体的成功标准然后把它们与潜在的实现领域作比较。 比如说，我要自动化下列工作：
我将在我的最重要成功标准之外评定这张列表上的每一项：
以我的情况，我认为没有必要弄得太精确。我分别使用了25，15，10和5作为我的评估界定数据。表2记录了结果。 表2：自动化表项的成功标准等级评价
根据表2的结果绘图（见图3）使得我可以比较容易地发现我应在何处投入时间和资源以获得最大的收益。 .
图3：投入自动化资源的最佳领域 维护模式下的版本验证和回归测试——然后是外语G11N测试——很明显是首先应突破的领域。在产品仍在变化之中的时候试图自动化设计将是非常不切实际的，因为它将涉及大量自动化重复工作。 通过改变考虑中的标准和工具，你可以把这一技术应用于很多项目和初始版本。图4概括了这些步骤。 
图4：一种区分自动化工具的引入的优先级顺序的技术的概括 结论一些软件开发工具的使用覆盖了整个开发周期，但是它们不能把顺序变成混乱。即使是最先进的工具也只能和它们支持的过程一样地工作。你的工具投资的回报将直接与你的过程成熟度级别成比例。级别越高，你可利用的特性就越多，你使用工具就越频繁，你使用的目的就越多。 如果你想要提高你的过程成熟度等级，引入自动化工具能够把你送上一个自然的进化过程达到这个目的。如果你正处在第一级并决定你要使用自动化工具，你必须首先写下你的测试步骤并使它们是可重复的；自动化工具本身则作为你由第一级升至第二级的催化剂。然后，在第二级，一旦你在一个组（比如测试）里建立了一个可重复的过程，你可以建立一个其它组可以采用的标准，这样你的自动化工具就成为了一个跨越测试，开发，需求工程，等等过程的共享基础设备。由于工具的使用你将可以进入更高的成熟度级别（第三级），而且工具将体现它的价值，因为更多人正在为更多目的使用它。你可以从那里开始使用工具来收集和跟踪每日工作进展和沟通数据，并实现到第四级的转变。最后，这一严格的数据收集将允许你精确地预报，计划，规划，和管理你的资源和项目，把你带到第五级。 我在这篇文章里提供的要点是容易实现的，并可以提高你任何工具实施的成功率。尽管如此，在最后，对你和你的团队是否确实已经准备好面对引入工具带来的挑战的决定权仍然在你。 我欢迎来自你们的反馈。如果你发现这些技术有所帮助请告诉我，并描述其它你的团队已经成功使用的技术。 附录A：检查过程的成熟度等级清单
附录B：测试过程的成熟度等级清单
附录C：在不同成熟度级别实现的IBM Rational工具
附录D：附加的CMM概况的笔记 所有改进努力的第一步都是相同的：一个现实的自我评估。CMM提供了研究会，指南，成熟度问卷，以及其他诊断手段来辅助这项评估。本文没有取代这些提供物；它只是向读者介绍CMM并提供跳跃地开始你的过程改进模型的要点。 为了恰当地评估你的组织，请单独看每一个开发阶段，并客观地调查不同级别上的不同从业者。 为了决定你的组织是否处于CMM第一级，判断你的软件和测试团队实践是否符合以下的任何一个描述：
如果来自项目管理团队高层和底层从业者的答案不同，不要感到惊讶。高层管理者可能会认为他们的组织是“高度成熟”的，因为他们相信满足外在的、可重复的数字和日期等同于过程按步骤进行。但实际上，为了满足数字和日期，工作雇员可能会放弃结构化代码回顾，不建立和记录可重复的单元测试，且不跟踪他们的设计变化。两个组的过程很可能无法集成以提供一个同步工作的环境。在这种情况下，我们需要对那些迭代使用低的成熟度级别并集中于标准的内容而不仅仅是数字。 这里有一个来自我自己的工作经历的尴尬例子。主要的目标是在一个具体日期前消除所有“未经核对的缺陷”。这些缺陷已经被找到，并提交以重新测试。我们知道，所有代码变化（比如，缺陷的修正）的10%将会造成其他问题，因此在一个特定日期前重新测试所有“未经核对的缺陷”使我们能够及时发现这些“预期”的错误并修改它们，提高产品的整体质量。要求的日期不断逼近，但是团队还落后于进程。为了赶时间，一些团队选择不经测试去除一些缺陷，留着潜在的10%的新错误。尽管这使得他们实现了标准的“文本”要求并使得他们的项目组件看起来稳定和符合目标，但实际上它破坏了质量目标的真实内容（发现那些新的错误）。 当团队感到压力，不得不以任何事为代价来“制造数字”时，那就是他们仍处于CMM第一级的信号。 参考您可以参阅本文在 developerWorks 全球站点上的 英文原文。 James Bach, "The Immaturity of CMM." American Programmer, 1994年9月。（指出了对CMM的常见抱怨。） Judy Bamberger, "The Essence of the CMM." Computer, 1997年6月。（来自CMM作者的值得一读的读物。） Bollinger and McGowan, "A Critical Look at Software Capability Evaluation." IEEE Software, 1991年4月。 Herbsleb et al., "Software Quality and the Capability Maturity Model." Communication of the Association for Computing Machinery (ACM), 1997年6月。 Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, 以及Charles V. Weber, Capability Maturity Model for Software, Version 1.1. Software Engineering Institute, CMU / SEI-93-TR-24, DTIC Number ADA263403, 1993年2月。 Mark C. Paulk, Charles V. Weber, Suzanne M.Garcia, Mary Beth Chrissis, and Marilyn W. Bush, Key Practices of the Capability Maturity Model, Version 1.1, Software Engineering Institute, CMU / SEI-93-TR-25, DTIC Number ADA263432, 1993年2月。 Software Engineering Institute, The Capability Maturity Model: Guidelines for Improving the Software Process , Addison-Wesley SEI Series on Software Engineering, 1995年。 注释1软件的能力成熟度模型，版本1.1，作者Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, 以及Charles V. Weber。 2工具选择是一个单独的并且是重要的过程；本文假设你已经完成了这一过程。 3Rational Application Developer强调了代码分析和代码形式级上的问题。它标示出代码设计，代码标准，全球化技术，以及任何其他Java或你为验证而使用的编码规则方面的问题。 4健壮性回归套件是一个测试组，你可以在一个开发阶段不断运行它来检验代码变化没有对产品产生负面影响（产生回归）。测试应当覆盖重要特性来帮助你判断产品是否足够稳定能够进入下一个开发阶段。测试集结构应当与下一个阶段对应，也要同质量结果对应。比如说，如果你从外面的来源（如订约人，一个公开源码产品等）采用了组件，测试就应该集中于互动点或外部和内部组件的集成区域。如果你发现很多缺陷或回归，你可以选择改变回归集或加入更多测试，基于那些问题区域。在一些情况下，你可能要采用一组遍及整个产品的缺陷修正。那样的话，你应该先集中于高级别客户的用例的健壮性回归。如果一个变化只与一个区域有联系，并且产品有一个非常稳定的质量跟踪记录，那么可以只集中于那个区域的测试。在最后，你将需要一个很小的覆盖了安装媒介的健壮性回归测试集——你不应该需要重新运行所有测试。 |