用 Rational 质量检验关方法提高软件质量并降低成本

转自:http://www.ibm.com/developerworks/cn/rational/09/qualitygates/index.html

今天的软件开发团队,正纠结在维护和修改软件的开发成本正不断飙升的烦恼之中。他们面临这样一种挑战:一方面要向商业客户交付高质量、高可靠性的软件产品,一方面却要降低总体成本来开发和维护所应交付的软件应用程序。在有些机构中,这已经成了 IT 压力的重要来源之一,并使低质量成为了返工问题中的核心问题。

IBM® Rational® 质量检验关方法(quality gates)可以帮助我们作为开发人员,来理解并控制我们所采用的软件开发生命周期方法。隐藏在质量检验关背后的思想是,在软件生命周期中转向下一个阶段或者子阶段时,我们需要看到这么做的信号。作为一个项目从一个阶段转向另一个阶段时的检查点,它们可以帮助我们提高软件的质量,因为它们可以确保我们正在执行的是最佳实践,而且与前期的结果相比较。详细检查的层次可以帮助我们分清开发中的重要事件,因此可以更早地解决质量问题。更早地发现问题,意味着它们解决起来成本更低,从而 IT 运作的总体成本也会降下来。

因此,实施质量检验关可以增加软件的质量,降低总体的成本。在软件开发的实践活动中,这种方案得到越来越广泛的应用。

基本原理(Rationale)

如果我告诉您,上周我绕着小镇逛了一圈,结果耗油量是 25 MPG (加仑/英里),您说这是好还是坏呢?没有一个基准,这可能很难回答。但是,如果我告诉您再上一周同样这样做的耗油量是 18 到 22 MPG。那现在您是否对上周我为何增加耗油量感到很好奇了呢?采取汽车保养最佳实践所产生的效应,例如更换机油或检查轮胎的气压,并不能用于准确地评价质量,除非我们确实找到了度量质量好坏的手段。

软件开发与此并没有什么不同之处。如果没有定量评价及记录结果的手段,是很难理解一项变更对软件开发是有积极影响,还是消极影响。您要怎样做,才能知道您上周向开发人员提供的培训课程能否带来好处?与机构内部开发的代码质量相比,您怎样才能知道外包项目质量的好坏?答案在于您是怎样创建评价方法的,以及从质量检验关收集到的度量数据。通过这种方式,您可以看到由于缩短最后期限日期对质量所带来的影响;根据是否满足既定的评价标准,您可以决定是否值得将项目继续进行下去。

一般来说,公司都会有一个处在构建阶段以及交付阶段之间的质量检验关:测试阶段。在向客户部署最后的产品之前,公司会进行测试以得到最后的交付许可。这对在部署之前测试机构记录每一项缺陷构成了极大的压力,这是不现实的。公司不能只依赖于一次最终的测试或者质量检验关,来确定整体的软件质量。公司需要更加灵活,这样在深入到开发阶段之前,他们就会考虑一下软件质量问题了。

检查点及最佳实践

在软件生命周期的早期阶段,关注其质量问题能够显著地提高质量及降低成本,而 Rational 质量检验关提供了开发阶段的检查点。简单地部署最佳实践,并不够好。您必须部署评价方法、基准以及重新评价标准,以帮助您确定软件需要能够跟得上软件需求。如果您的项目投资人不能理解,怎样在决策制定过程中使用最佳的操作手段以及好的过程,那么仅仅拥有它们就并不足够。执行者在评价最佳实践时总是会低估它们。在我的软件开发生涯的早期,我的管理团队要求我确保所有的代码拥有一个主要的作者,以及与其相联系的二级人员,以评审 —一般叫做同等代码评审的评审。在同等代码评审中,二级人员对评审和评价主要作者的工作负责。同等代码评审持续有大约一周的时间(与缺乏任何实际的执行相结合),这种“最佳实践”会被丢弃掉。

软件开发由一系列的阶段组成。这些阶段对于所有形式的操作都是相同的,包括瀑布过程、Rational 统一过程(Rational Unifies Process,RUP)、OpenUp 以及所有敏捷方法。在每一个阶段中,都有一个需求阶段、设计/编码阶段、构建阶段、测试阶段以及发布阶段。更重要的是,所有的阶段都有与之相联系的质量检验关,因为您可以为每一个阶段使用多个质量检验关。例如,在测试阶段的中期,您可能想要一个评审质量检验关,以在执行任何测试之前自动化测试脚本框架认证过程。在软件生命周期的早期阶段创建这种质量检验关,可以帮助您更早地发现缺陷,这样就可以花费更少的成本来修复它。在大多数情况下,在需求评审中找到一个需求问题,要比等到程序设计好、编码好,构建好以及测试好之后再找到,成本要低得多。

需求阶段

第一个阶段是需求阶段。大多数的软件开发生命周期的最佳实践,是追踪与测试用例相关的需求。这可以帮助您理解您的需求,而且在您运行软件时它能提供更好的用户经验。通过识别和跳跃性地开始测试过程,书写测试用例可以向您提供很大的帮组。这种最佳的操作允许您基于测试用例的复杂性、风险以及功能性区域来安排它们的优先级,来建立关于测试将要持续多久的质量估计。它还能寻找测试中的再使用过程,并开始构建一个测试框架。

这就是使用像 IBM® Rational® Quality Manager 工具这样方案的地方,以获取测试用例,帮助满足质量目标。为了实现这一点,您可以使用 Rational 工具来获取您的需求。Rational 工具为追踪需求提供了多个工具。这些工具的多样性将会发挥作用,而 Rational Quality Manager 在环境中拥有基本的需求追踪功能。Rational Quality Manager 可以帮助您简化追踪过程,需求有一个测试用例与之相关,而报告功能会向管理团队提供关于项目的可视性,以评价与项目相关努力的质量。Rational Quality Manager 通过获取风险、复杂性以及一系列的其他元数据来支持您的过程,以安排测试活动的优先级。使用这些信息,您就可以评审需求,以找到哪一个需求最容易实现自动化的。Rational Quality Manager 还可以帮助您为重复使用创建相关的工作。我们需要怎样做,才能将这种最佳实践转化为一个质量检验关?一种方法是将这个质量检验关与其他的质量检验关联系起来,并使用 IBM Rational Insight 工具来向管理人员报告,或者使用 Rational Quality Manager 解决方案中内建的报告功能。使用 Rational Insight 方案,您可以将追踪范围与元数据联系起来,以获取关于以上任务完成情况的报告。


图 1. 基于需求测试范围使用 Rational Quality Manager 的质量检验关
饼状图显示设计到的 50% 需求以及未涉及到的 50% 需求

设计和编码阶段

软件开发生命周期的设计和编码阶段,为单元测试的质量检验关提供了一个机会。有一些软件操作发展了测试驱动的开发过程,这又为质量检验关提供了一个机会。Rational Quality Manager 可以帮助获取单元测试相关的元数据,并引用单元测试,这样您就可以实现单元测试的成功应用了。这些信息可以得到评审和报告,帮助您识别,代码是否需要得到单元测试认证,以及单元测试成功执行的程度。使用 Rational Insight 方案,您就可以将这些任务集成到一个评价好的、基准化的质量检验关。

构建阶段

构建阶段向您提供了一个方法,将质量检验关导入到您的软件开发生命周期中。创建质量检验关的一种方法,便是使用静态分析,来将 Rational 技术集成到构建过程中。静态分析与 Microsoft® Word® 程序中的拼写和语法检查器相类似。静态分析会扫描源代码,以寻找普通的程序错误,与 Microsoft Word 扫描文件以寻找拼写和语法错误相类似。更特别的是,静态分析能够寻找与编码形式相关的编码,以识别基本的代码漏洞。此时,结构分析可以帮助识别类的附属,并定位循环附属、轴心以及其他的结构。另外,结构分析有助于评价软件的复杂性,提供数据流分析,并降低所有来自于预编辑源代码的 —性能问题。软件还可以扫描安全性问题,例如跨站点的脚本以及 Structured Query Language (SQL)注射脆弱性。Rational 为代码评审提供了两个产品:IBM Rational Software Analyzer 企业 RSAR 以及 Ounce Lab 分析提供了专家代码评审的价值,而不需要代码评审过程的普通方面。两种工具都可以轻松集成到构建过程中,并生成关于怎样完善源代码的报告。这些报告可以作为质量检验关,帮助您决定继续到测试阶段是不是实际的,或者是否需要重新评价源代码。这些质量检验关可以与其他的质量检验关联系到一起,例如使用 Rational Insight 环境生成的需求质量检验关。导入这个层次的质量,可以帮助您确保您采用的源代码不是太复杂,并且满足最佳编码操作的需求。


图 2. 构建阶段中基于 Ounce Labs 的质量检验关
Ounce 文件管理员操作板的屏幕截图

图 2 的大图。)

测试阶段

在测试阶段执行质量检验关,可以向您的团队提供一些选项。测试门可以包含到测试阶段的几乎所有方面。您可以考虑执行的一个质量检验关,是将质量检验关集成到测试框架中。这就迫使您去评审测试脚本,以确保在手动测试步骤中得到重复利用。这些测试框架质量检验关可以获取测试用例搜索的高层次情况,以便进行重新利用。评价方法应该来自于可重复使用测试步骤的数量,以及不可重新使用测试步骤的数量。这种检查点允许管理人员去决定,自动化是否应该继续,以及是否应该花更多的时间去验证测试创建的过程。


图 3. 使用 Rational Quality Manager 基于测试执行状态的质量检验关
显示使用 EWI 专户执行状态的条状图

最终测试阶段

在最终测试阶段中,Rational Quality Manager 方案可以提供关于通过的以及未通过的报告、产生的缺陷、严重缺陷的数量以及其他的状态的信息。这些测试结果是最佳实践的一部分,以提高项目的质量,并且可以使用 Rational Quality Manager 环境来获取,并且可以轻松升级为测试变更。在这个区域中,Rational Insight 工具通过将这些信息汇编到一个报告中,可以帮助您改善这个过程,这些报告可以得到轻松的追踪,并由管理人员来评价。

使用质量检验关来改进开发过程

改善由业务分析员、程序员以及测试者所完成的工作,同时让它们变得更加有效果和效率,对于软件开发过程的成功十分重要。使用 IBM Rational Jazz™ 技术来存储这个输入的“幕后”内容,您可以使用 Rational Insight 方案来轻松创建质量检验关。这些质量检验关十分基本:在不需要会议、审查或者评价方法的基础之上,就可以查看和理解它们。因为 Rational 工具会完美地获取关于软件开发生命周期的信息,而不用对您的开发过程产生什么影响。

当您在开发过程中使用质量检验关(quality gates)时,控制和理解您所采用的软件开发周期方法可以改善您的开发过程。质量检验关通过帮助确保采用了最佳实践手段,并与过往的项目相比较来提高软件的产品质量。这种详细检查的过程帮助您理解您正在开发的软件的发展趋势,给您创造一个机会在软件开发的早期阶段就意识到所存在的质量问题。经验证明,在早期阶段发现存在的缺陷,可以使得修复它们成本更低,进而降低 IT 运作的成本。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14780914/viewspace-628343/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/14780914/viewspace-628343/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值