内容


通过自动化工具的实施提高你的CMM水平

Comments

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

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

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

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

概述:能力成熟模型

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

 Figure 1: The five levels of software process maturity

Figure 1: The five levels of software process maturity

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

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

表1:成熟等级的特点

1级:初始软件过程被认为是特别的,有时甚至是混乱的。很少有详细定义的过程,而且成功取决于个人努力。
2级:可重复的基本项目管理过程被建立起来,能够跟踪成本,时间进度和功能。必要的过程原则能够在有着相似应用程序的项目上重复早期的成功。
3级:清楚定义的管理和工程活动的软件过程都被文档所记录和标准化,并被集成入一个标准的软件过程以备组织使用。所有项目都使用一个被认可的,专用版本的开发和维护软件的组织标准软件过程。
4级:良好管理的详细的对软件过程的度量和产品质量信息被收集起来。软件过程和产品被量化地理解和控制。
5级:最优化从过程和领先的创新思想及技术中获得的量化的反馈激活了不断的过程改进。

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

工具实施和过程改进

如果你已经意识到在你的开发周期中的一或多个方面使用自动化工具的需求,并已经评估了你的目标和为你的需要选择了合适的工具,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%的成功,这仍是一次很好的学习经历。

Figure 2: Timeline summary

Figure 2: Timeline summary

图2:时间进度概况

Rational Application Developer在开发周期的开始阶段是最有用的,因此让我们看看你主要在开发周期最后应用的工具是如何提高过程的成熟度的。这将指出这些概念实际上是多么通用。

示例:测试自动化工具

为了证明我的观点,我为测试过程建立了近似于待检查的模型的一个成熟度模型(见附录B:测试过程的成熟度模型)。

当你的步骤需要多次重复时,自动化工具是最有效的。但是在初始级别,没有可重复性。你的测试是特别的,没有任何记录,也没有任何东西需要自动化。

在第2级,当你把你的测试步骤和环境写入文档时,你有了你可以自动化的基线。随着你在成熟度谱上的推进,达到第三级,你继续在开发和测试团队中介绍详细定义的标准。这使得你能够创建一个开发,发布工程和测试都可以使用的自动化测试基础设施。由于更多人正在从中受益,你将从自动化中获得更多价值。

如果你一直运行你的自动化测试,你将获得关于测试时间的数据,产生的典型问题,以及影响你的效率的因素等方面的信息。这是你能够进入到第四级,你将可以更好地管理你的测试时间表和错误率——甚至可以预报发布时间。

在第五级,你进行的是最优化。你可以把其他应用链接到你的自动化测试基础和测试框架上。你还可以结合一些应用,它们可以自动跟踪代码的变化,跟踪测试覆盖,提交错误,检查代码外形和存储使用,等等。在这一级上,你组织中的更多人可以获得更多特性的更大好处并实现更多目标。换句话说,你的成熟等级越高,你将发现更多人利用工具的优势。而他们使用工具越多,他们进入下一个成熟等级就更容易。

无论你处于哪个等级,你可以建立一个协作的和连续不断的改进环境——一种工具和过程成熟度等级间的最优关系。(如果需要关于如何更快推进成熟度等级的建议,请参看附录C)。

确定“第一项任务”

工具实施中的一个重要因素是决定在何处引入它:能够展示工具的全部能力和价值的最佳“第一项任务”是什么呢?我开发了一种技术来帮助你回答这个问题。

作为一个例子,让我们再回到测试自动化工具。向自动化的实现投资并不便宜,而且你需要一定的头脑和技术来取得成功。这就是为你的自动化工具认真选择合适的“任务”的重要性所在。我用来决定引入新的工具的时机的步骤如下:

  1. 定义一个好的测试的应具备的品质。
  2. 确定引入成功的标准。
  3. 确定你可能想要使用工具的所有领域。
  4. 根据成功的标准将这些领域排序。
  5. 当你向每一个领域引入工具后,将结果制表;决定你在何处取得最大收益并据此调整优先级。
  6. 根据你制定的图表优先级清单,管理你的自动化资源。

为了进一步说明,让我们按照上述六个步骤引入自动化测试工具。首先,下面是一个好的测试的标准(这不是一个无遗漏的列表,仅是一个示例)。

  • 测试可以运行三次以上。
  • 测试可以在多个平台和环境下运行。
  • 测试将是每日“健壮性回归套件”4的一部分。
  • 自动化安装和退出清除步骤在每一次新的建立之前能够运行。
  • 测试将存在于一个“高通讯/高代码变化”的区域。
  • 测试将存在于一个带有多个功能点(高集成度点)的代码区域,该区域被多个开发者所使用(高风险)。
  • 测试将复制一个需要几个高级测试员来运行的人工回归套件;它将只需要一个初级测试员来运行。
  • 测试将覆盖一个带有若干与之有矛盾的缺陷的领域。
    • 这包括了从带有集成点的领域到带有若干个与之有矛盾的缺陷的领域(高风险)。

一旦你理解了这些好的自动化测试的大体标准,你就可以创建更为具体的成功标准然后把它们与潜在的实现领域作比较。

比如说,我要自动化下列工作:

  1. 建立我的团队每天都要在每个程序版本上运行的验证测试
  2. 一个人正在工作的产品上的新代码
  3. 维护发布上的回归测试集
  4. 经常变化的界面的接受测试
  5. 在所有外语机器上的健壮性测试

我将在我的最重要成功标准之外评定这张列表上的每一项:

  • 发布中的测试周期数
  • 人工测试中涉及的人数与自动化运行中涉及的人数之比
  • 产品稳定性:我可以在不进行大量自动化测试脚本重写的情况下实现我的目标吗?
  • 自动化实现需要的时间与人工测试运行需要的时间的比较:如果人工测试只需要十分钟来建立和运行,投入几个月的时间编码实现自动化还值得吗?

以我的情况,我认为没有必要弄得太精确。我分别使用了25,15,10和5作为我的评估界定数据。表2记录了结果。

表2:自动化表项的成功标准等级评价

周期数用户数稳定性实现难易程度总计
新设计的建设周期11057
建设时期后的直接新产品回归测试51051030
在新产品过渡时期的回归测试51051030
维护模式下的回归测试1510101045
版本验证测试251101551
G11N平台的冒烟测试15510535
总计66374055

根据表2的结果绘图(见图3)使得我可以比较容易地发现我应在何处投入时间和资源以获得最大的收益。

.

Figure 3: Best areas to spend automation resources

Figure 3: Best areas to spend automation resources

图3:投入自动化资源的最佳领域
点击放大

维护模式下的版本验证和回归测试——然后是外语G11N测试——很明显是首先应突破的领域。在产品仍在变化之中的时候试图自动化设计将是非常不切实际的,因为它将涉及大量自动化重复工作。

通过改变考虑中的标准和工具,你可以把这一技术应用于很多项目和初始版本。图4概括了这些步骤。

Figure 4:  Summary of a technique for prioritizing automated tool introductions

Figure 4: Summary of a technique for prioritizing automated tool introductions

图4:一种区分自动化工具的引入的优先级顺序的技术的概括

结论

一些软件开发工具的使用覆盖了整个开发周期,但是它们不能把顺序变成混乱。即使是最先进的工具也只能和它们支持的过程一样地工作。你的工具投资的回报将直接与你的过程成熟度级别成比例。级别越高,你可利用的特性就越多,你使用工具就越频繁,你使用的目的就越多。

如果你想要提高你的过程成熟度等级,引入自动化工具能够把你送上一个自然的进化过程达到这个目的。如果你正处在第一级并决定你要使用自动化工具,你必须首先写下你的测试步骤并使它们是可重复的;自动化工具本身则作为你由第一级升至第二级的催化剂。然后,在第二级,一旦你在一个组(比如测试)里建立了一个可重复的过程,你可以建立一个其它组可以采用的标准,这样你的自动化工具就成为了一个跨越测试,开发,需求工程,等等过程的共享基础设备。由于工具的使用你将可以进入更高的成熟度级别(第三级),而且工具将体现它的价值,因为更多人正在为更多目的使用它。你可以从那里开始使用工具来收集和跟踪每日工作进展和沟通数据,并实现到第四级的转变。最后,这一严格的数据收集将允许你精确地预报,计划,规划,和管理你的资源和项目,把你带到第五级。

我在这篇文章里提供的要点是容易实现的,并可以提高你任何工具实施的成功率。尽管如此,在最后,对你和你的团队是否确实已经准备好面对引入工具带来的挑战的决定权仍然在你。

我欢迎来自你们的反馈。如果你发现这些技术有所帮助请告诉我,并描述其它你的团队已经成功使用的技术。

附录A:检查过程的成熟度等级清单

成熟度等级示例:检查
初始
  • 当前只有非正式的(或没有)评估过程。
可重复的
  • 关键主要检查的参与者受过检查方面的教育。
  • 检察员有一星期时间为检查作准备。
  • 所有检查由个人完成,有一个受过训练的监督员。
  • 检查统计数据被记录下来,累积的数据在操作评估会议上被汇报。
清楚定义的
  • 所有主要的和次要的检查参与者都接受过检查方面的教育。
  • 组织确定并训练了一定(与整个团队规模成比例)的敬业的监督员。
  • 检查被限制在每人隔两天一次两小时的检查。
  • 检查团队很小(三到八人之间)。
  • 检查通常(75%以上的时间)在产品完成前进行。
良好管理的
  • 所有的检查参与者受过检查方面的教育。
  • 指定了当地的受支持者/领导。
  • 工作进展被按照个人分析以改进每一个部分(比如,代码,测试用例,设计文档,等等)。
  • 检查几乎总是(90%以上的时间)在产品完成前进行。
最优化
  • 工作进展被分析并且行动计划基于发布范围的检查数据为整个发布所规格化。
  • 监督员和团队合作改进检查过程,实践进展,和工具——在项目的进行中和结束后。

附录B:测试过程的成熟度等级清单

成熟度等级示例:检查
初始
  • 没有正式的测试过程
  • 有特别的测试或由客户进行测试
可重复的
  • 由运行测试的个人写下的测试计划
  • 由运行测试的个人写下的测试用例
  • 没有共享或由他人进行的测试
  • 没有覆盖或需求跟踪
  • 没有总体测试基础设备
清楚定义的
  • 满足测试组计划标准
  • 测试团队两人组写下的测试
  • 由开发,测试员,文档,产品经理进行的检查
  • 一组测试员和开发者运行人工测试
  • 与技术支持和客户培训职员共享的测试
  • 标准测试基础设备的开始
良好管理的
  • 指定本地的测试工程受支持者/领导
  • 工作进展被按照个人分析以改进每一个部分(比如,测试用例,测试跟踪需求,测试覆盖,等等)。数据被用来预报项目的结束以及未来项目时间规划。
最优化
  • 工作进展被分析并且行动计划基于发布范围的测试和质量数据为整个发布所规格化。
  • 监督人和团队合作在项目期间和后面改进测试实践,工作进展,以及工具。

附录C:在不同成熟度级别实现的IBM Rational工具

等级软件过程特点用以进入下一个级别的IBM Rational工具
1特别的并且有时是混乱的;很少有过程是详细定义的。IBM Rational Application Developer -- 在初始化的快速浏览第一级设置
2基本项目管理过程已就位来跟踪成本,时间表和功能。IBM Rational RequisitePro用以完成需求跟踪

IBM Rational TestManager用以管理不同的测试工件

IBM Rational Application Developer -- 在成熟度第二级设置以包括下一级别的时间和结果

IBM Rational ClearCase用以识别代码版本和跟踪代码变化

IBM Rational ClearQuest用以跟踪和分析缺陷
3工程活动被记录到文档,标准化,并集成入一个标准的软件过程。IBM Rational Application Developer -- 设置为第三级,带有政府政策验证,比如可访问性和全球性

IBM Rational Component TesterIBM Rational Functional Tester用以自动化单元和特性/组件领域
4量化理解和控制的详细度量已就位。IBM Rational Application Developer -- 设置为第四级,关注移动性和性能最优化

IBM Rational PurifyCode Coverage在建立周期中被自动化并汇报单元测试覆盖数据和性能/存储使用

IBM Rational Functional TesterIBM Rational Performance Tester用于性能和系统级测试
5量化的反馈和创新的思想及技术激活了不断的过程改进。IBM Rational Rose从细化到设计被使用

IBM Rational Application Developer -- 设置为第五级以从环境,语言和操作系统包含移动性;G11N规则也被设置和检查

IBM Rational Application Developer同首次开发实现模型一起使用来平衡基于Rational Rose模型情景的早期测试用例

附录D:附加的CMM概况的笔记

所有改进努力的第一步都是相同的:一个现实的自我评估。CMM提供了研究会,指南,成熟度问卷,以及其他诊断手段来辅助这项评估。本文没有取代这些提供物;它只是向读者介绍CMM并提供跳跃地开始你的过程改进模型的要点。

为了恰当地评估你的组织,请单独看每一个开发阶段,并客观地调查不同级别上的不同从业者。

为了决定你的组织是否处于CMM第一级,判断你的软件和测试团队实践是否符合以下的任何一个描述:

  1. 为了获得灵活性,软件过程大体是在项目过程中由从业者和他们的管理者临时准备的。
  2. 即使确定了一个软件过程,它不是严格维护或强制从每个阶段或迭代中严格执行的。
  3. 团队的焦点是解决眼下的危机(救火)。
  4. 当强加了严峻的截止时间时,产品的功能和质量不得不对时间表做出妥协。
  5. 意图是加强质量的活动,比如结构化的评估和测试,在项目落后于时间表时经常被削减或取消。

如果来自项目管理团队高层和底层从业者的答案不同,不要感到惊讶。高层管理者可能会认为他们的组织是“高度成熟”的,因为他们相信满足外在的、可重复的数字和日期等同于过程按步骤进行。但实际上,为了满足数字和日期,工作雇员可能会放弃结构化代码回顾,不建立和记录可重复的单元测试,且不跟踪他们的设计变化。两个组的过程很可能无法集成以提供一个同步工作的环境。在这种情况下,我们需要对那些迭代使用低的成熟度级别并集中于标准的内容而不仅仅是数字。

这里有一个来自我自己的工作经历的尴尬例子。主要的目标是在一个具体日期前消除所有“未经核对的缺陷”。这些缺陷已经被找到,并提交以重新测试。我们知道,所有代码变化(比如,缺陷的修正)的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健壮性回归套件是一个测试组,你可以在一个开发阶段不断运行它来检验代码变化没有对产品产生负面影响(产生回归)。测试应当覆盖重要特性来帮助你判断产品是否足够稳定能够进入下一个开发阶段。测试集结构应当与下一个阶段对应,也要同质量结果对应。比如说,如果你从外面的来源(如订约人,一个公开源码产品等)采用了组件,测试就应该集中于互动点或外部和内部组件的集成区域。如果你发现很多缺陷或回归,你可以选择改变回归集或加入更多测试,基于那些问题区域。在一些情况下,你可能要采用一组遍及整个产品的缺陷修正。那样的话,你应该先集中于高级别客户的用例的健壮性回归。如果一个变化只与一个区域有联系,并且产品有一个非常稳定的质量跟踪记录,那么可以只集中于那个区域的测试。在最后,你将需要一个很小的覆盖了安装媒介的健壮性回归测试集——你不应该需要重新运行所有测试。


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=161813
ArticleTitle=通过自动化工具的实施提高你的CMM水平
publish-date=08012005