软件质量度量研究分析

软件质量度量研究分析（精选7篇）

软件质量度量研究分析 篇1

摘要：随着软件的复杂性日益增长,软件开发的周期以及费用也日益增长,软件质量的保证与提高越来越成为了人们高度重视的问题。解释了软件质量的概念和质量模型的发展阶段,分析了软件质量度量的过程以及度量的验证与预测,提出了几种针对软件质量的度量方法,最后对软件质量的度量做了相关的展望。

关键词：软件质量,度量,质量度量模型,度量验证

在过去几十年里,因为软件的质量问题而导致整个系统发生失效的事例屡见不鲜,进而给人类生命安全和环境造成了巨大的损失。20世纪80年代,美国有两个系统,耗资5600万美元的Univac联合航空订票系统和耗资2.17亿美元的高级后勤系统都因在交付使用后发现不满足要求而被迫进行重新研制[1];而在1996年6月,在阿丽亚娜5号火箭首次发射后不到一分钟的时间内,就因为软件故障问题致使火箭发生了爆炸,导致了巨大的经济损失和相应计划的延迟[2]。因此软件的质量问题已引起了人们的极度重视,软件质量的度量问题自然也得到重视。

由于计算机技术、数据融合技术、网络技术和通信技术的飞速发展,人们对软件性能及功能提出的要求也越来越高,度量软件质量已成为一个迫切需要解决的问题。如何通过选择合适的软件质量指标体系、确定软件质量的量化过程和方法来进行客观性地度量,对于评价软件的质量是关键的一步,进而对于减少软件失效的发生和提升软件的总体质量也是具有极其重要的意义。

1 对软件质量模型的认识

1.1 软件质量及定义

至今为止,软件质量还没有一个统一的、惟一的定义,不同的组织或应用可能会有不同的定义。ANSI/IEEE Std 729—1983定义软件质量为:与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体[3];M.J.Fisher给出的定义为:表征计算机软件卓越程度的所有属性的集合。由此可知,软件质量的优秀程度与反映软件各项功能、性能需求的特性及其组合紧密相关,如果针对软件本身设计出来的质量特性能够满足各种要求和反映软件质量需求,则说明软件产品的质量等级比较高。结合各种定义,软件质量反映了以下三个方面的问题:1)显式的软件需求,包括用户方、交办方等提出来关于软件的功能需求、性能需求等,这是软件质量度量最基础的需求;2)隐式的需求,在软件生命周期中其中有一部分需求并没有明确提出来,如可维护性等;3)软件的整个开发过程还必须按照一定的方法,规范来进行,缺少这些,就无法指导软件开发人员的各种开发活动,开发秩序会变得杂乱无章,软件质量也就得不到一定的保证。

综上以上的定义和最新的研究可以将软件质量定义为:软件所具有的能够满足功能和性能需求、遵循一定的开发准则和规范以及符合隐含的一些规定需求的本质。

1.2 软件质量度量模型

软件度量工作自1958年Rubey和Hurtwick首次提出软件度量学概念[4]至今,大体经历了三个阶段。1976年,Boehm等人从可移植性、可使用性、可维护性三个方面来定量的评价软件质量为第一阶段;第二阶段以1978年Mc Ca1l等人从“产品运行、产品修正和产品转移”提出的质量度量模型即“质量要素———评价准则———度量”为标志。但是实践证明通过该模型不同缺陷的反馈信息可能相同,以致指标的制定及其定量的结果难以评价。随后,国际标准化组织(ISO)[5]于1985年和1993年先后提出了多项关于软件质量度量技术的工作报告,其提出的软件质量度量模型将软件度量工作带入了第3个发展阶段。

通过对这三个模型的深入研究发现,这三个模型都着重分析了软件质量属性的影响因素,这些模型研究的对象主要是软件产品,即在软件质量属性和软件设计、编程的特性之间建立关联映射[6]。这些模型可以帮助加深对软件特性的研究,有利于分析和建立特定软件系统的质量特性及其特性组合。但是这些质量度量模型都存在一定的局限性,每个模型都是针对软件本身提出来的,通用性比较强,在应用到具体的软件系统评估中,并不能很好地反映软件所具有的特殊性。因此,如今很多模型都是根据自己的需求来开发建立的,虽然软件自身的性质给模型的确定带来了一定的困难,但是总的提升还是有的。文献[7]就指出了一种基于全局和局部质量标准的框架,降低了模型建立的难度;文献[8]中指出了从领域报告问题、用户关键情况和用户满意度等级三个方面来寻找度量元,利用数据统计分析的方法加强了软件质量的管理。这些方法的开发和应用都为软件质量特性和模型的设计提供了很好的引用和借鉴。

2 软件质量的度量研究

2.1 软件质量度量过程

软件的度量过程主要可以分为五个步骤进行:1)确定软件的质量度量需求。这一步是软件质量度量最为前提和基础的一步,主要活动包括设计可能的质量因素集合,优化并确定这一因素集合和建立软件质量模型。2)确定软件质量度量元。这是软件度量过程较为关键的一步,度量元选取的好坏直接影响着质量评估的结果。首先在基于软件质量度量框架的基础之上,将质量特性分解成度量元;继而执行度量元的成本效益分析,根据其结果调整优化已选度量元集合。3)执行软件质量度量。包括定义度量数据收集过程并且收集数据、根据已有数据计算度量值等环节。需要注意的是,采集的数据应该基于正确定义的度量和模型,从而保证数据的正确性、准确性和精度;因此,在收集数据之前,应当设定数据采集的目标,并且定义有意义的问题[9]。4)分析软件质量度量结果。通过分析比较收集的度量数据与目标值,发现两者之间的区别。确定那些不可接受的度量值,详细分析那些数值偏离关键值的度量元并依据分析结果重新设计软件质量度量。5)软件质量度量的验证。验证的目的就是为了证明通过软件产品和过程度量可以预测具体的软件质量因素值。验证的过程中,在运用相关的验证方法和标准的前提下,必须确定软件质量因素样本和度量样本,然后执行对度量的统计分析,检验度量的作用是否实现。整个具体过程如图1所示。

2.2 软件度量的验证与预测

软件度量的验证是软件度量领域另一个非常重要的话题,因为实际上软件度量的认同取决于软件度量是否能作为软件质量特性的预报器,如果能,度量验证的目的也就达到了[10]。

从软件产品度量验证实质来分析,具体反映了以下三个问题:1)软件产品度量必须量度本应该量度的内容,例如耦合度量量度耦合性等。2)软件产品度量和一些重要的外部度量存在关系,例如可维护性和可靠性的量度。3)软件产品度量能促进现有的度量水平的提升,这种提升意味着将会产生降低度量收集的复杂性以及提高预测错误的可能性等等优势。

在进行软件度量验证时,我们必须注意软件度量的外部验证和内部验证的区别,内部验证考虑同态,也就是说,做用户想要的度量。软件度量的外部验证考虑量度是否和软件品质属性(外部变量)有关系。文献[11]和文献[12]应用算法验证进行度量的外部验证,而Zuse等人采用的是所谓原子修正进行度量的外部验证,原子修正可以看作对顺利量表的必要条例。软件度量广泛使用的外部验证概念相对于外部特征是相互关系的考虑。文献[13]也从内部验证和外部验证的角度出发,提出了利用理论验证和经验验证相结合的方式来对已存在的五个有关面向对象设计的质量因素的度量集进行验证。软件组织可以利用这种方法尽早确定高风险的软件模块、构建设计和编程计划与方针以及进行系统级的预测。具体方法如图2所示。

最近的研究表明,验证软件产品度量的方法的质量越来越受到人们的关注。主要基于两个原因:1)应用于软件工程度量验证的一些一般实践在科学性方面令人难以接受;2)对于有效的工程管理和可靠合理的经验研究,有效的测试和验证是必须的。因此,必须对那些来出自于研究室的度量的有效性进行验证,才可能达到准确性和科学性。更需注意的重点是软件度量验证不只是一次的事,它是一个需要重复验证的连续过程。

2.3 软件质量度量方法与进展

2.3.1 面向结构度量方法

较早出现的度量是建立在结构化程序设计和模块化思想基础上的,分析的对象包括程序的控制流图,实现中的操作复杂性,方法间的传递耦合和流程耦合等。其中影响比较大的有McCabe提出的循环计数复杂度度量,直到今天历经改进,仍然被实践者所采纳。McCabe 1976年提出了环形复杂度(cyclomatic complexity)理论,该理论以图论为基础,通过分析程序的控制流图来获得程序的复杂度,为度量程序逻辑复杂性提供了一种很好的方法。

2.3.2 面向软件复用的度量

20世纪90年代后期,软件复用的研究兴起。复用的度量主要包括可复用性度量和复用度量[14]。可复用性度量主要用来判定一个构件的可复用性和质量,复用度量主要用于判定复用对生产率、质量和开发时间的作用,它可以在不同级别上进行度量,包括构件级、产品族级、项目级和机构级。目前面向复用的度量大致可分为以下4大类:经济模型类、成熟度模型、复用比率模型以及复用潜力度量模型。

2.3.3 面向对象度量方法

软件度量进一步作的开展主要在80、90年代,尤其是在90年代,软件度量的研究获得了空前的发展。1989年,Morris研究讨论了面向对象应用程序的度量,Bieman讨论了在面向对象条件下软件重用的度量问题。1993年中国台湾学者J-Y Chen和J-F Liu提出chen&liu方法[15],从操作性、复杂性、重用性、类的属性等八个方面去度量面向对象软件。1994年Chidamber和Kemerer发表论文对面向对象度量提出了基于继承树的一套面向对象度量方法[16]被称为C&K度量方法,主要用来量度与对外部质量属性的影响有关的面向对象设计的复杂性[17]。1995年,brito等人针对面向对象属性提出的一套称之为MOOD的度量算法集[18],它从封装性、继承性、耦合性和多态性等四个方面给出了面向对象软件六个度量指标。1998年,Nesi和Querci提出了一种新的软件复杂度和大小度量方法[19]。

到了2000年,Arlene F提出一种预测点度量方法,这种方法基于对象和他们的特征,建立一种适合预测工作量和跟踪生产力的方法,核心是每类加权方法数(Weighted Methods per Class WMC)[20]。2001年,Victor和Daily提出了一种基于构件点的度量方法叫SPECTRE的方法[18],用于预测开发任务时间和模块规模。2003年,Washizaki等提出了一种可重用组件的度量方法,用于度量面向对象组件的易理解性和可重用性。同年,Hastings和Sajeev介绍了一种新的Vector Size Measure(VSM)方法,用于在软件生命周期的早期度量软件规模,软件分类,软件开发结果等[21]。2005年Gyimothy等提出一种基于经验的面向对象度量方法,该方法能有效地实现对源码的bug预测度量。同年,Del Bianco等采用经验断言的方法,扩展了功能点度量方法,并将其应用到面向对象度量中。

3 展望

毫无疑问,软件度量是提高软件品质的一个重要方法。只有通过软件度量,才能确定软件产品所具有的属性组合与所希望的符合程度。Dieter Rombach,曾在巴黎说到过(现在他在美国软件工程实验室(SEL)工作):我们现在不再是问我们是否应该度量,而是怎么样度量。尽管过去软件度量领域做了许多的研究,但还有许多问题未解决。

首先,目前还没有成熟的度量方法,大多度量方法适用性不强,且有些还存在着度量过程客观性差,度量结果不准确的问题;

其次,国际上还没有统一的软件度量标准,很多标准针对的范围比较小,并不能满足软件质量度量的整体要求。

将来,理论开发(对现实的假定)变得越来越重要,相关和归约分析需要考虑讨论度量比例,外部变量对软件度量验证确认是未来需要研究的课题。利用测量理论的公理有助于更好理解软件品质和成本估计后潜在的内容;同时,针对现有问题进行深入的研究和分析,探求符合需要的理论方法和开发工具将对未来度量领域的发展起到重要的促进作用。

4 结束语

软件质量度量作为一个很模糊和深奥的问题,已经成为软件开发者、使用者以及维护者必须做的一项基本性的工作。如何客观地和定量地说明、评价和度量开发产品的质量,如何以客观数据为基础,并与软件开发技术相结合,开发出高质量的软件产品,也已变得越来越重要。本文所提出的关于度量方面的内容及相关问题对于后续的研究具有一定指引意义,也是作者今后学习和研究的方向。

APP软件质量度量的研究 篇2

关键词：APP软件,质量特性,质量度量

0 引言

随着移动互联网时代的来临,APP软件迅猛发展,导致各种APP软件层出不穷。这些软件丰富了手机的功能,使手机从单一的通讯工具发展成为了个人信息收集和处理的移动平台。[1]然而,由于APP软件的开发一般基于开放操作系统,设计简单、开发门槛较低、进入市场周期较短,同时,由于市场上的应用软件产品呈井喷式增长态势,加上市场监管较弱,没有针对性的APP软件质量检测模型,这些APP应用在为人提供方便的同时,由于其本身的缺点,也产生了很多问题,给人们带来了无法估量的损失[2]。

1 APP软件的质量现状

软件质量是对明确陈述的功能和性能需求、明确记录的开发标准以及对所有专业化软件开发应具备的隐含特征的符合度。如何保证软件产品的质量,更好的服务用户,同时在合理的人力物力条件下开发出高效率,高可靠性的软件产品已成为人们的迫切需求[4]。例如,软件运行过程中出现功能失效、死机、重启、丢包、响应慢、不稳定;软件内容涉嫌黄赌毒;甚至软件本身涉及窃取账号、购物欺诈、恶意扣费、窃取隐私信息、垃圾广告、骚扰用户等,这些质量问题严重损坏了终端消费者合法权益[1][3]。

人们期望APP软件能够稳定,安全,快捷,具备友好的用户界面。因为APP软件与传统软件有着很大的不同,度量和测试方法也不一样。所以研究APP软件的度量方法来有效、正确和便捷地衡量和保证APP软件的质量显得非常必要[5][6]。

2 APP软件的特征

APP软件不像传统的桌面软件那么庞大,它是运行在移动端的软件。软件对GUI界面的交互性和美观性要求高。APP软件有着诸如面向特定应用,实时性,平台固定,高可靠性等特征。APP软件与传统软件的区别如表1。

APP软件自身具备如下的显著特点:

2.1 实时性

实时性即在规定时间内系统对外来事件作出响应的能力。

实时性是APP软件最首要的特点。移动设备的功能越来越多样化,比如交通导航,通信,聊天,在线支付等。当用户在使用相关交通类软件进行交通导航时,软件必须实时的响应用户的需求,实时的给予当前位置的准确定位,随用户的移动实时的更新当前位置。

2.2 简单易用

APP软件的最明显的特征是用户体验,要让用户使用起来方便、好用。APP软件可谓大众化的软件,它不像传统的财务类软件,ERP软件,管理类软件,这些软件是面向特定用户的,而APP软件则是侧重于一定的实用功能,面向大多数用户的。它的用户群体比较广泛,从儿童到中年人,老年人,从知识分子群体到未受教育群体。用户群体的广泛多样性决定了APP软件必须是简单容易使用的。

2.3 高可靠性

可靠性即软件在规定时间内,特定条件下执行特定功能的程度。

在以上实时性要求的基础上,APP软件还要具备较高的可靠性。APP软件是随时随地使用满足即时需求的软件,当出现错误的输入、不稳定的网络环境等极端条件时,APP软件要具备维持现有规定功能的能力,或者要有相应的容错处理机制,而不能出现卡顿,闪退,软件崩溃,无响应等状况。如微信用户通过微信向某微商用户了解商品打算购买,而微信则不能在可接受的时间内将信息发送给对方,甚至会漏发消息,这就给用户带来了损失。

3 APP软件的度量方法与度量指标

不同行业的软件,质量特性及其子特性的重要性是不同的,根据APP软件的特点,本文从功能性,易用性,性能效率,兼容性这四个方面对APP软件的度量进行研究。

3.1 功能性

软件功能是软件质量最基本的内容。

APP软件的功能性即APP软件在特定条件下使用时,软件产品提供满足明确和隐含要求的功能的能力。APP软件功能性的子特性中重点关注软件产品所要实现要求的正确性、完整性、适当性。其中正确性关注需求是否被开发人员正确实现,以及需求、设计、实现的阶段是否存在问题。完整性关注软件需求中的所有功能是否被全部实现,是否存在遗漏,软件的所有需求是否全部被满足。功能性的度量指标及说明如表2。

3.2 易用性

APP软件的易用性是要满足软件容易使用的目的,APP软件而言,其特性应包括容易理解性,易学习性,用户错误防护,用户界面的美观性等特性。这些特性是由APP软件的大众化特性决定的。因为具有多样的用户群体,所以APP软件就要容易操作,容易被各种各样的人群掌握,其界面的美观性要能够吸引用户。每个特性的度量指标及说明如表3。

3.3 性能效率

目前移动软件发展面临的两个问题:减少内存和通信压力。这些问题的解决可提供软件的稳定性。[6]所以,APP软件的性能效率关注的是软件在运行过程中所占用的内存,CPU,电量等资源和事物响应的速度。参考25010通用质量模型概括为两个方面,时间行为、资源利用率。性能效率的度量指标及说明如表4。

3.4 兼容性

移动设备的运行平台多种多样,开发出能在多种平台上运行至少能支持主流平台的软件花费成本很大。因此,如何解决多种多样的测试平台和项目测试成本之间的矛盾是问题的关键所在。[6]APP软件的兼容性侧重于软件与其他软件及操作系统的共存性,软件与其他软件能够各自正常运行,彼此不受影响,这些统称为共存性。兼容性的度量指标及说明如表5。

4 结束语

本文分析了APP软件的特点,针对APP软件的特征提出了APP软件应重点关注的质量特性及相应的度量指标和度量方法,可以作为相关开发人员的度量参考和第三方评测机构的软件评价依据。

参考文献

[1]郭文胜.智能手机APP质量模型[J].中国西部科技,2014,13(11):1-3.

[2]顾春来.APP应用程序开发模式探究[J].硅谷,2014,7(5):35-36.

[3]Liu Z,Hu Y,Cai L.Research on software security and compatibility test for mobile application[C],2014 Fourth International Conference on.IEEE,2014:140-145.

[4]王晓鹏,丁晓明.基于模式的软件质量模型研究与应用[J].计算机与现代化,2007(6):26-29.

[5]吴坚,吴刚.软件质量模型的研究[J].计算机工程与科学,2006,28(8):125-127.

论软件质量工程的度量与模型 篇3

关键词：软件质量,成熟度,缺陷,度量,模型

1 什么是软件质量

质量是个多维的概念,质量的“维”包括:感兴趣的实体、对实体的观念和实体的质量属性。按大众化的观点,质量是一个无形的特征:可以讨论,可以感觉和评判,但不能称、也不能量。大众观点的误解和含糊无助于产业界的质量改进工作。专业观点认为,质量能够而且应该被定义、测量、监控、管理和改进。

对于软件,最狭义的产品质量就是产品中没有“bug”,这个定义通常以两种方式表达:缺陷率、可靠性。为了提高整体顾客满意程度以及针对各种质量属性的满意度,一定要将质量属性考虑进软件的规划和设计中。软件质量的另一种观点是关于过程质量对最终产品质量的观点。从顾客需求到软件产品的交付,开发过程是复杂的,而且经常涉及一系列的阶段,每个阶段又有反馈路径。每一阶段都为中间用户生产中间交付物,每个中间交付物有某种影响最终质量产品的质量属性。

为了在开发期间改进质量,我们需要开发过程模型,并且在此过程中需要选择和部署具体的方法和途径,确保开发过程受控于满足产品质量目标的度量和模型。

2 过程成熟度框架和质量标准

评估一个机构或项目过程成熟度的框架,包括SEI和软件生产力研究公司(SPR)的过程成熟度评估方法、Malcolm Baldrige制度和评估过程以及ISO 9000认证过程。SEI和SPR方法是针对软件过程的,后两个框架实际上应用于所有产业的质量过程和质量管理标准。

2.1 SEI过程能力成熟度模型(CMM)

卡耐基-梅隆大学的SEI为软件开发工作建立了一个过程成熟度框架,框架包括过程成熟度的5个级别:初始级、可重复级、已定义级、已管理级、优化级。SEI成熟度评估框架已经在软件产业的政府代理和公司中使用。评估方法依靠一个有85个条目回答“是”或“否”的问卷,对每个问题,指出了与这个问题相联系的SEI成熟度级别。

软件度量和模型的普遍使用是第四级成熟度的关键特征,而对第五级而言,缺陷预防是关键。在软件机构中已经对许多项目进行了SEI成熟度评估,这一模型也被美国国防部用作合同软件的评价载体。

2.2 SPR评估

在SEI成熟度模型建立的同时,软件生产力研究公司开发了SPR评估方法。SEI和SPR方法之间有很大程度的相似,也有一些本质的不同。SEI的问题重点在软件机构的结构和软件过程,SPR的问题则包括战略性的共同问题以及影响质量、生产力和用户满意度的策略性的项目问题。SPR问卷的总问题数大约是400个。此外,SPR问题是链接式的多重选择问题,回答用5级尺度(优秀、好、中等、及格、查),而SEI方法是用二分尺度(是、否),SPR方法的整体过程评估也用同样的五级尺度表示。SPR开发了一个自动化软件工具,用于评估以及资源规划和质量预测。

正在使用的具体开发过程、这个过程的成熟度等级和公司的质量管理体系是影响软件项目质量的重要因素。

3 软件质量度量

软件度量分为3类:产品度量、过程度量和项目度量。软件质量度量是软件度量的一个子集,重点在产品、过程和项目的质量方面。一般来说,软件度量同过程度量和产品度量的联系要比与项目度量的联系更密切。

软件质量度量可进一步划分为最终产品质量度量和中间产品质量度量。软件质量工程的本质在于研究中间度量、项目特征和最终产品质量之间的关系,并在这些发现的基础上,策划过程质量和产品质量的改进。此外,还应从整个软件生命周期的角度看待质量,应当将维护过程质量等级的测量作为另一类软件质量度量包括到度量里来。

3.1 产品质量度量

通常用软件中的“bug”个数或软件在遇到“崩溃”之前可运行多长时间来测量内在产品质量。在操作式定义中,这两个度量是:缺陷密度和平均无失效时间。平均无失效时间度量经常被用于空中交通管制、航空电子学、武器系统等对安全要求非常高的系统上,缺陷密度在商业软件系统中使用得较多。缺陷密度和平均无失效时间是内在产品质量的两个关键度量。相应地,存在两种主要的软件可靠性增长模型-失效间隔时间模型、缺陷计数(缺陷率)模型。

3.2 过程中质量度量

和最终产品质量度量相比,过程中质量度量的定义不够正式,软件开发人员中的实践方法也千变万化。一方面,过程质量度量只是为某些机构跟踪正式机器测试期间出现的缺陷;另一方面,有一些建立了良好软件度量程序的软件机构,其软件度量程序覆盖了开发周期每个阶段的各种参数。

当软件还在测试之中时,每KLOC(或其他分母)的缺陷数就是质量的一个良好指示器。它对于监控在同一个开发机构内的统一产品的后续发布版本特别有用。

3.3 软件维护的度量

在软件维护阶段,按时间区间的缺陷出现数和按时间区间的顾客问题召唤数都是事实度量。事实度量虽然重要,但不反映软件维护的质量。在维护阶段可以做的事是尽可能快地、以优秀的修补质量修补这些缺陷。下列度量很重要:①修补积累和积累管理指数;②修补响应时间;③逾期修补百分数田;④修补质量。

4 软件可靠性模型

在把软件产品提供给顾客的时候,可以使用软件可靠性模型对它的可靠性和潜伏缺陷数进行估计。可以将可靠性模型粗略地分成两类:静态模型和动态模型。静态模型使用项目或程序模块的属性来估计软件中的缺陷数。动态模型通常是基于统计分布的,使用当前开发的缺陷模式来估计最终产品的可靠性。

软件质量估计的静态模型的一般形式:y=f(x1,x2,…,xk)+e其中,因变量y是缺陷率或缺陷数,自变量xi是产品、项目或开发该产品过程的属性,e是误差项(因为模型不能完全解释因变量的行为)。公式中自变量的系数是基于以往产品的数据估计出来的。对于当前产品或项目,自变量的值是测量出来的,然后插到公式中,推导出因变量的估计值-产品缺陷率或缺陷数。

静态模型的参数的系数是基于许多以往项目估计出来的,动态模型的参数是基于从感兴趣产品至今所收集来的多重数据点估计出来的。如果分析的单位是在产品级而且目的是估计产品级可靠性,静态模型要比动态模型差些。动态软件可靠性模型又可进一步分为两类:用于整个开发过程建模的和用于后期正式测试阶段建模的。前者以Rayleigh模型为代表,后者以指数模型和其他可靠性增长模型为代表。动态模型的共同之处是它们都被表示为开发中的时间或其逻辑等价物(例如开发阶段)的函数。

5 可靠性增长模型

Rayleigh模型对整个开发过程中缺陷模式进行建模。与Rayleigh模型相比,可靠性增长模型通常是根据正式测试得到的数据建模。通常是在软件提交给顾客使用之前和开发工作完成前,用软件可靠性模型进行可靠性预测。它们同样可用于为现场失效模式或缺陷出现模式建模,并为维护计划提供有价值的输入。

指数模型是软件可靠性增长模式的基本形式之一。软件可靠性建模已经成为软件工程中最活跃的领域之一,在各种专业报刊和软件学术会议中提出了多种模型,每一种模型都有它的假设、适用性和局限性,大部分模型都没有在实用环境中用真正的数据检验过,实际使用的更少。

可靠性建模是用精确的统计术语来概括的复杂现实的一种尝试。因为正被建模的物理过程(软件失效现象)很难精确统计,在建模过程中必须无歧义地陈诉基本假设。在应用中,基本假设符合时,模型可以运行的好一些,反之亦然。假设越合理,模型就越好。一般说来,失效间隔时间模型的假设要相对更严一点。此外,收集失效间隔时间数据的费用更高,并且要求数据的精确度要更高。

6 质量管理模型

开发工作完成时,评估软件产品质量、预测缺陷数、或者估计发现到下一个失效的平均时间是重要的。更为重要的是在软件开发过程中对软件质量的管理和监督。虽然一些模型可用于可靠性评估和质量管理两个方面,但这些模型如何用于质量管理和如何用于可靠性评估是不同的。一方面,质量管理模型必须能够提供早期警报信号或者改进信号,这样就可以及时地计划和执行相应的行动。另一方面,与预测模型相比,质量管理模型在一定程度上不够精密、不够数学化。因此,将可靠性模型用于质量管理,而不是作为预测性工具的时候,需要不同的关注点。

对于一个开发机构来说,如果想使所使用的质量管理模型发挥作用,它就必须覆盖早期开发阶段。可靠性增长模型是基于当开发工作实际完成时的系统测量数据的,对过程中质量管理不像对可靠性评估那样有用,但在跟踪当前状态和决定何时结束对具体预定质量目标的系统测试方面,可靠性增长模型对质量管理是有用的。

6.1 Rayleigh模型框架

对质量管理来说,Rayleigh模型是一种好的整体模型。Rayleigh模型涉及到缺陷预防和与前期项目相关的早期缺陷排除等内容。在这个模型的基础上,如果降低错误的注入率,那么Rayleigh曲线下的面积就将变小,导致较小的预测现场缺陷率。同样,如果在开发过程中的前期排除的缺陷较多,那么在后期测试和维护阶段的缺陷率就会较低。这两个方案的目的都是为了减少最后测试阶段的缺陷数量,进而导致较少的应用现场缺陷。

比质量预测更为重要的是Rayleigh框架可用作质量改进策略的基础-尤其是与缺陷预防和早期缺陷排除相关的两个原则(即前面提到的两个假设),这两个原则是开发质量改进策略的主要方向。

Rayleigh模型给出了双向质量改进策略。简略地说,目的就是要把Rayleigh曲线的最高点移到左端,同时尽可能地降低这个最高点。最终目标是获得最低曲线所代表的缺陷注入/排除模式。不管机构的缺陷排除模式是否符合Rayleigh曲线,都可以实现这种策略。如果不符合Rayleigh曲线,可以采用离散的、基于阶段的缺陷模型。必不可少的是要制定一个基于阶段的缺陷排除目标,以反映与基线相比的较早的缺陷排除模式,然后按照活动计划来完成这个目标。

6.2 PTR子模型

如果现存的参数模型同缺陷模式不相符合,就必须开发专门的模型用于评估过程中的质量。在大规模软件开发过程中,现有可靠性模型不能应对的一个共同实际问题是连续集成问题。要对一系列准备好了的程序模块加以集成,并且这种集成发生在整个开发周期直到系统测试开始。无参数PTR子模型是为测试跟踪开发的。在许多开发机构中可以通过某种问题跟踪报告(PTR)对测试缺陷加以跟踪,PTR子模型是整体缺陷排除模型的一部分。

预期的整体PTR率可从历史数据估计出来。随时间变化的集成代码可以在当前的实现计划中获得。代码集成后的PTR表面模式依赖于测试活动和驱动器构造进度。PTR模型是一个无参数模型,目的是使得可以在过程中质量管理的实际测试缺陷出现曲线和理想/预期曲线之间进行比较。

6.3可靠性增长模型

可靠性增长模型对开发后期阶段的质量管理也有一定的用处,可以使用从以前产品或者同一产品的以前发布版本开发的模型来跟踪当前产品的测试缺陷。当把可靠性增长模型作为一个质量管理工具时,好处之一就是当获得第一个数据点时,马上就可以对之进行比较。可靠性模型在质量管理的使用比可靠性预测方面更为自由。可靠性模型对质量管理的典型用途就是根据所给可靠性目标、或者是要达到的某个具体缺陷水平确定测试结束日期。如果从当前数据推导出的模型指出没有达到希望的质量,那么我们就要进行更多测试,直到可靠性达到期望的目标为止。

在开发的后期阶段基于可靠性模型来管理开发质量,不应该把这个模型作为单独的模型使用。软件开发质量管理系统应该尽可能地关注早期阶段,如果观察到一些负面指标,就必须尽可能地采取相关行动。

7 结束语

软件产业是我国产业革命的先锋及高新技术产业的重要组成部分,它作为实现国民经济和社会信息化的先导产业而占据了主要位置。然而,我国软件产业的现状并不乐观,软件企业普遍存在“软件危机”,如质量不能为用户接受,工期超时,费用难以控制等问题。软件质量是软件企业的生命。

在软件乃至其他产业中,质量的实际操作式定义由两级组成:内在产品质量、顾客满意度。顾客满意度是质量的最终确认。产品质量和顾客满意度构成了质量的全面含义。事实上,全面质量管理(TQM)区别于传统质量工程只关注产品质量的根本点在于:TQM是旨在通过将质量与顾客满意度结合达到长期的商业成功。除产品的满意度,还必须分析顾客对公司的满意度。在这个现代质量时代,提高顾客满意度是商业成功的底线。

参考文献

[1]严圣武,张大庆,王建昌.质量控制[M].北京:万象出版社,1998.

[2]何新贵,王伟.软件能力成熟度模型[M].北京:清华大学出版社, 2000.

[3]ISO/IEC JTCl/SC7/WG6,ISO/IEC 9126-1:Information Technology Software Quality Characteristics and Metrics-Part I Quality Model [S].

软件质量度量研究分析 篇4

关键词：软件度量,中小型软件企业,CMMI

0.前言

度量是根据一定的规则, 将数字或符号赋与系统、构件、过程等实体的特定属性, 从而使我们能清晰地理解该实体及其属性。即度量就是对事物属性的量化表示。软件度量是针对计算机软件的度量, 是对一个软件系统、组件或过程具有的某个给定属性的度的一个定量测量。通过度量, 可以对软件给出客观的评价, 可用于指出软件属性的趋势, 能有针对性地进行改善。从软件企业的观点出发, 软件度量是通过各种不同的量度对软件生命周期中的各个元素进行度量。现代软件工程理论认为, 要想控制软件质量就必须进行软件度量, 软件度量是成功实施过程改进的保障。

1. CMMI中的软件度量

度量和分析 (Measurement and Analysis, MA) 是CM-MI中的一个关键过程域。它属于阶段式表示法中的管理级或者连续式表示法中的支持工程。它是针对所有活动需要采集数据, 进行分析设置的活动[1]。该活动要求项目组在开始时, 就需要考虑各种活动的性能和质量的表征参数, 设置合适的度量方法, 更重要的是能对这些采集的度量数据进行分析, 度量和分析活动是用于进行决策和进一步行动的依据。它的两个特定目标是:协调度量和分析活动;展开度量和提供结果[2]。

1.1 协调度量和分析活动的具体内容

(1) 确定度量目标:度量目标是为项目展开用, 是为能够采取相应的纠正措施, 是与项目的计划和目标以及组织的目标相适应的。该实践的产出物有:文档化的度量目标。

(2) 细化度量:将度量目标进一步精炼成精确的、定量的度量值度量, 可分为基本度量和衍生度量。基本度量可以直接获得, 如工作产品规模的估计和实际值、工作量和成本的估计和实际值以及质量度量 (缺陷数、缺陷严重性) 等;衍生度量则是取自其他多个数据, 进行某种计算而得到, 如进度性能指数、缺陷密度、测试或验证覆盖率、可靠性度量值等。该实践的产出物有:基本度量和衍生度量的描述。

(3) 数据采集和存储的规程:确定要采集的数据, 确定如何采集和存储这些数据, 建立数据采集的过程指南, 尽可能采用自动采集的工具和方法。该实践的产出物有:数据采集和存储规程。

(4) 确定分析规程:确定如何分析数据, 同时也再次检查是否采集了必需的数据。该实践的产出物有:分析说明和规程、数据分析工具。

1.2 展开度量和提供结果的具体内容?

(1) 收集度量数据:基本和衍生度量数据集合、数据完整性测试报告。

(2) 分析度量数据:分析数据, 提供草案报告。

(3) 存储数据和度量结果:存储信息的目的是为将来使用, 否则存储是没有意义的。

(4) 通报度量结果:定期将分析结果传送给相关人员, 便于决策和采取纠正措施。

2. 基于CMMI的中小型软件企业的软件度量

2.1 建立软件度量流程

中小软件企业软件度量过程中的四个关键步骤为:目标的设立, 规程的制定, 数据的收集分析, 结果的分析利用[3]。其中每个关键步骤都包含若干子步骤, 它们之间相互依赖, 彼此支持, 流程图如图1所示。

2.2 关键步骤的定义

2.2.1 目标的设立

(1) 确定度量目标

CMMI的MA过程域中明确要求度量的行为要与所需要的目标相一致。所以, 在进行度量定义和实施前, 首先要明确组织或项目的目标, 并对其含义和要求达成一致的理解, 以便将它们作为确定度量目标的基础。例如, 组织目标是“打造优质产品”, 那么, 就需要对“优质产品”的内容进行详细的定义。通过编写《组织/项目目标详解》, 保证所有人员对目标有清楚一致的认识。

(2) 确定关键成功因素和关键过程

关键成功因素是决定项目或组织达到既定目标的因素。获知组织的关键成功因素, 是确定哪些过程活动将给组织带来最大利益的基础。

2.2.2 制定规程

规程是指导度量具体实施的标准和依据, 涉及人员的职责, 资源的使用和度量活动的周期等关键信息。在定义度量规程之前, 首先要明确需要度量的对象, 即度量元。

(1) 度量元的选择

中小型软件企业可在GQM模型的指导下结合企业本身的特点有针对性的选取一些度量元进行度量。如软件规模、工作量、缺陷率、生产率、计划时间和实际完成时间、开发人员的平均经验水平、文档质量、里程碑数、需求变更数、缺陷的解决时间等。

(2) 度量元的定义

为了确保不同的人、不同时间都能对所使用的度量元有着一致的理解, 需要定义组织或项目的《度量元操作定义表》, 用来反映度量元中各数值的含义、数目、得到方式、收集人员、产生频率、使用工具等。

2.2.3 收集分析数据

(1) 收集数据

数据收集要体现简单、方便、明确原则。所使用的方法和渠道可以是多种多样的。最简单是方法是利用表格形式进行填写。但这种方法存在表格不同版本的一致性问题, 大量表格的统计、管理、保存问题等。工具的使用往往会解决上述问题, 并使数据的收集和统计更加规范化、简单化, 自动化。如果数据的收集工具能和其他管理工具结合使用, 则会起到事半功倍的效果, 如;软件缺陷管理管理工具 (BUGZILLA、ClearQuest) 或项目管理工具。

(2) 存储分析数据

CMMI中要求组织和项目级都要建立度量数据库。度量数据库可以根据度量元操作定义建立, 支持对数据的各种检索。度量数据库的建立为组织数据的统一存储、管理和利用提供了方便, 并为数据的利用提供了唯一的出口。在进入组织度量库之前, 所有数据必须经过严格验证, 以确保其正确性和可靠性。

2.2.4 结果的利用

(1) 分析数据并交流结果

在度量数据分析时, 应该紧密围绕目标进行, 使用适当的分析方法。常用度量分析技术包括:散点图、趋势图、直方图、Pareto图、条形图、控制图等。通过这些图表可以直观地反映过程的稳定性、变化趋势、影响过程性能的因素之间的关联等。

(2) 使用度量结果进行软件过程改进

如果过程是满足目标的, 则需要考虑优化过程以实现更高的目标。如果过程还不能充分满足目标, 可以利用CMMI5中的CAR过程域进行原因分析, 找出主要的因素, 并将其作为过程改进的需求纳入组织过程改进计划中, 使组织有针对性地对过程实施改进, 并对改进结果做出量化评价。

3. 结语

度量技术是软件质量的定量反映, 根本目的是为了对个体和系统进行评估或对未来发展进行预测。中小型软件企业软件的度量应与软件开发过程紧密结合才能对软件进行有效的度量, 要把度量细化到每个程序设计阶段, 不是只在软件开始的时候进行度量, 要对每一个里程碑结束后进行有效的度量以使程序适应或修正前期度量。

参考文献

[1]罗运模, 谢志敏.CMMI软件过程改进与评估[M].北京:电子工业出版社, 2004.

[2]毕春兰.软件开发过程中CMMI的软件度量[J].科技情报开发与经济, 2007, 17 (33) .

软件质量度量研究分析 篇5

随着软件复杂程度和规模的增长, 软件开发成本和周期相应不断增加, 引发是软件开发风险的增加, 软件质量很难得到有效的控制[1]。为能够生产高质量、低成本、周期短的软件产品, 企业越来越重视评审在软件开发过程中发挥的作用[2]。评审的目的就是找出可能影响软件产品质量、以及在开发过程、维护过程的试用性和环境方面的设计缺陷, 同时采取补救措施, 找出在性能和经济方面的可能改进。虽然评审不能从源头上解决软件开发中存在的成本和缺陷产生的问题, 但在软件过程管理和持续改进方面起到的作用却是不能被忽视的。

1 基本理论

软件能力成熟度模型集成 (CMMI) 其所依据的想法是:集中精力持续努力去搭建有效的软件工程过程基础结构, 不断进行过程改进和管理实践, 克服软件开发中的困难。软件评审过程度量的应用主要是采用软件度量学的方法对软件评审质量进行科学评价, 通过量化管理和监控软件开发过程, 合理分配资源, 修定有效可行的软件开发计划, 在提高质量的同时降低软件开发成本[3]。这种软件过程质量的量化管理为软件评审过程的持续改进奠定了基础, 也为管理层对项目后期如何开展提供参照依据。文章使用主成分分析法通过研究软件评审度量指标体系的内在结构关系, 将多个评审度量指标转化为少数几个相互独立且包含原来指标大部分信息 (86%以上) 的综合指标。其优势在于确定的权数是基于数据分析而得出的指标之间的内在结构关系, 不受主观因素影响, 具有较好的客观性, 而且得出的综合指标 (主成分) 之间相互独立, 减少信息的交叉, 这对软件评审的分析评价极为有利。

2 软件评审

2.1 评审流程

软件评审分为4类:管理评审、同级评审、项目后的评审、状态评审, 文章重点研究同级评审, 同级评审流程图如图1。

同级评审最终输出《评审检查表》和《评审报告》。

2.2 评审过程的质量因素

同级评审的目标是发现缺陷, 其中包含预审提交的缺陷数量和评审后确认的缺陷数量。鉴于评审工作产品的规模和类型不同, 不以绝对的缺陷数量来评价评审质量。在评审过程中搜集了15项度量元, 整合为7个度量要素, 软件评审过程质量要素分解表如表1所示:

3 主成分分析法

主成分分析是设法将原来众多具有一定相关性指标 (比如P个指标) , 重新组合成1组新的互相无关的综合指标来代替原来的指标。通常数学上的处理就是将原来P个指标线性组合, 作为新的综合指标。最经典的做法就是用F1 (选取的第1个线性组合, 即第1个综合指标) 的方差来表达, 即Var (F1) 越大, 表示F1包含的信息越多。因此在所有的线性组合中选取的F1应该是方差最大的, 故称F1为第1主成分。如果第1主成分不足以代表原来P个指标的信息, 再考虑选取F2即选第2个线性组合, 为了有效地反映原来信息, F1已有的信息不需要再出现在F2中, 用数学语言表达就是要求Cov (F1, F2) =0, 则称F2为第2主成分, 依此类推可以构造出第3、第4, ……, 第P个主成分[4]。

3.1 主成分模型

主成分模型:

须满足以下条件:

(1) 每个主成分系数平方和为1, 即:

(2) 主成分之间互不相关, 即:

(3) 主成分方差依次递减, 即:

3.2 主成分分析法综合评价模型的具体步骤

3.2.1 评审度量数据采集及相关系数矩阵

根据表1所示的度量要素和计算公式, 搜集某企业21个同行业软件项目 (P1至P21) 的评审相关度量数据。将软件评审度量数据进行标准化处理, 把数据转换为标准正态分布, 计算相关系数矩阵, 反馈出各指标之间的相互关系 (表2) 。

3.2.2 特征方程及主成分确定

通过统计产品与服务解决方案软件 (SPSS) 进行运算分析, 得到软件评审度量指标的相关系数矩阵特征值及其对应的特征向量 (见表3) 。一般取特征值大于或等于1, 累积贡献率大于85%的因子作为主成分[5], 由表4看出, 提取4个综合因子可以基本反映全部指标的信息, 可以描述原变量信息达到87.4%。

通过表4所示的主成分载荷情况, 需求的确认度、需求的无二义性在第1主成分上载荷值较大, 与第1主成分的相关系数较高, Y1反映了需求识别能力, Y1得分越大, 表示项目的需求识别能力高;评审缺陷识别率、问题处理率和评审阶段缺陷排除率在第2主成分上的载荷值较大, Y2反映了缺陷排除能力, Y2得分越大, 表示项目的缺陷排除能力强;缺陷密度在第3主成分上的载荷较大, 相关程度较高, Y3反映了问题发现能力, Y3得分越大, 表示项目的问题发现能力强;评审人力率在第4主成分上的载荷较大, Y4反映了评审人力效率, Y4得分越大, 表示项目的评审人力效率高。

3.2.3 主成分值以及综合分值

运用SPSS软件进行主成分分析, 运行生成因子成分得分系数矩阵和模型, 得到各主成分线性组合模型:

式中:X1, X2, X3, X4, X5, X6, X7分别指评审缺陷识别率、评审人力率、问题处理率、需求的确认度、需求的无二义性、评审阶段缺陷排除率、缺陷密度的标准化指标。Y1, Y2, Y3, Y4分别指软件评审度量指标的第1, 2, 3, 4主成分值。

3.2.4 评价等级及数据分析

依据各主成分线性组合模型, 计算每个项目的主成分值, 并按得分值的大小进行排序, 得到21个项目的4个主成分得分矩阵 (表5) 。

根据主成分得分矩阵可以得出:21个项目在软件评审过程中的需求识别能力、缺陷排除能力、缺陷发现能力、评审人力效率的相对水平, 也能够反馈出项目的评审执行效率。数据的差异反应了项目在评审过程中的需求识别能力、缺陷排除能力、缺陷发现能力、评审人力效率等方面的差异。依据表5的数据分析:首先确认项目的需求识别能力评价分值为正, 即在需求分析充分的条件下, 依据缺陷排除能力、缺陷发现能力评价分值的大小判别项目在缺陷排除及发现的水准。评审人力效率的评价分值大小直接反映评审过程的工作量水平。通过以上数据分析找出评审过程中的薄弱环节加以改进, 在实践中检验其可行性, 为项目后续工作的有效开展提供参照和建议。文章采用的主成分分析法根据各度量指标的贡献率大小确定, 不仅克服人为确定权重的缺陷使得综合评价结果唯一, 而且客观合理。

4 结束语

通过对评审质量的分析, 可以发现评审过程中可能存在的不足, 以便提前采取有效措施来降低评审产生的不利影响, 同时也可为后期的过程改进提供建议。软件评审过程的度量分析结果反映评审过程的运作情况, 经过数据分析、过程评价、过程控制及过程改进, 进而不断地完善评审体系, 达到提高评审质量和降低评审成本的目的。评审过程质量的度量方式有很多, 研究侧重点也不尽相同, 这就需要人们继续研究和持续改进, 软件评审过程质量的度量分析工作还具有更为广泛的研究前景。

摘要：软件能力成熟度模型 (Capability maturity model integration, CMMI) 被众多企业重视及推广应用, 这不仅体现一个软件开发单位的CMMI等级, 而且可以帮助软件开发单位进行自我检验, 不断优化单位的软件开发过程, 提高软件质量, 软件开发效率, 提升客户对产品的满意度。文章依据CMMI相关过程域对软件评审过程度量的支持框架, 参照企业实际情况进行评审过程质量的度量分析, 运用传统的过程度量方法以及统计技术对软件评审过程度量进行研究。

关键词：软件能力成熟度,软件评审,质量因素,软件评审过程度量,主成分分析

参考文献

[1]侯红, 丁剑洁.软件度量与软件过程管理[M].北京:清华大学出版社, 2009:40-41.

[2]张万军, 郑宁, 赵宇兰, 等.基于CMMI的软件工程及实训指导[M].北京:清华大学出版社, 2011:74-152.

[3]李健.软件过程质量度量与控制[M].北京:清华大学出版社, 2005:56-68.

[4]于秀林, 任雪松.多元统计分析[M].北京:中国统计出版社, 1999:78-143.

软件测试成本度量基本方法研究 篇6

关键词：软件测试,成本估算,数据采集,度量分析

0引言

随着软件在各行各业的日益普及,越来越多的企业和用户意识到软件测试的重要性,第三方软件测试行业快速发展。如何预测、评估、控制软件测试成本成为当前研究的重点。软件测试成本度量[1]是对软件测试项目的成本进行数据定义、收集以及分析的持续性定量化过程。PMP[2]从项目经理的角度对项目成本管理进行了规范,CMMI[3]从项目组织层面对如何度量进行了规范。然而,目前国内尚缺乏软件测试成本度量方面的规范。本文对软件测试成本度量方法进行了研究,从软件测试成本的构成、软件测试成本度量的过程、软件测试成本度量的应用三方面阐述如何开展软件测试成本度量工作,为软件测试团队和第三方软件测评机构的测试成本度量提供科学依据。

1软件测试成本构成

软件测试成本由直接成本和间接成本构成。直接成本包括直接人力成本和直接非人力成本,间接成本包括间接人力成本和间接非人力成本。软件测试成本构成[4]如图1所示。

(1)直接人力成本包括软件测试人员的工资、奖金、福利等人力资源费用。对于非全职投入软件测试人员,按照在软件测试项目中的工作量占其总工作量比例折算其人力资源费用。软件测试人员一般包括测试项目负责人、测试分析员、测试设计员、测试程序员、测试人员、测试系统管理员、配置管理员。一人可承担多个角色的工作,一个角色可由多人承担。其中,当软件供方实施测试时,配置管理员由软件开发项目的配置管理员承担;当独立的测试组织实施测试时,应为测试活动配置管理员。

(2)直接非人力成本包括软件测试方为测试该项目而产生的办公费、差旅费、培训费、业务费、采购费及其它未在以上项目列出,但确系软件测试方为测试此项目所花费的费用。

(3)间接人力成本指软件测试方服务于测试管理 整体需求的非软件测 试人员人 力资源费 用分摊 ,包括质量保证人员 、组织级技 术管理人 员等的工 资 、奖金、福利等分摊 。

(4)间接非人力成本 指软件测 试方不为 测试某个 特定项目而产生,但服务于整体 研发活动 的非人力 成本分摊,包括软件测试方场地房租、水电、物业,软件测试人员日常办公费用分摊及各种研发办公设备的租赁、维修、折旧分摊。

2软件测试成本度量过程

软件测试成本度量过程[5]包括软件测试成本的估算、软件测试成本的测量和软件测试成本分析三部分。

2.1软件测试成本估算

2.1.1软件测试成本估算基本流程

软件测试成本估算基本流程如图2所示。

本文所指的被测软件是指具有测试计划或测试合同、具有软件测试所需的各种文档,系统边界已确定、需求描述明确、编码工作基本完成且版本受控的软件。软件测试成本估算从软件规模度量开始,对工作量、工期、成本进行估算,可充分利用基准数据,采用方程法、类比法或类推法。

2.1.2软件规模度量

功能点(FP)与代码行(LOC)是常用的两种软件规模度量方法[6]。然而,随着近年来可视化编程工具、模板库、类库的广泛采用,程序中有大量自动生成的代码、复杂的自动配置脚本或资源 文件设置,在采用这 些工具的 项目中,用LOC进行软件规模度量已经不够准确。相对而言,近年来FP方法得到了不断的改进和完善,其历史数据也有了非常大的积累,技术日趋成熟。鉴于上述两种方法的优缺点,本文选用功能点估算方法。

在软件规模度量前,估算人员应根据测试计划或测试合同中规定的测试范围确定系统边界,然后再根据已确定的系统边界和需求描述、项目特点和度量需求进行软件功能规模度量。在软件规模度量时,估算人员应考虑可能的测试需求变更程度,并对规模度量结果适当调整。

度量的方法可选用国际标准化组织ISO/IEC已发布的以下5种功能规模度量标准 中的一种,即:1ISO/IEC19761(COSMIC-FFP方法);2ISO/IEC 20926(IFPUG方法);3ISO/IEC 20968(MkⅡ 方法);4ISO/IEC 24570(NESMA方法);5ISO/IEC 29881(FiSMA方法)。

根据相关国际标准中的方法适用范围声明,COSMIC方法适用于商业应用软件和实时系 统;IFPUG方法[7]适用于所有类型软件的功能规模度量;MkⅡ方法[8]适用于逻辑事务能被确定的任何软件类型;NESMA方法与IFPUG方法非常类似,但对功能点计数进行了分级,以便在估算的不同时期选择不同精度方法进行估算;FiSMA方法适用于所有类型软件的功能规模度量。

2.1.3工作量估算

工作量估算[9]需要考虑的因素众多,如测试存在的风险、测试中资源可复用的程度等。工作量估算可分估算准备、估算与调整两步。工作量估算的准备主要是分析测试的风险、确定影响测试的主要因素;估算与调整主要是根据风险分析结果,对估算方法或模型进行合理调整,根据软件测试复用情况的分析,调整工作量估算。

2.1.4工期估算

对软件测试工期的估算[10]主要有以 下几种方 式:1根据工作量估算结果和资源情况,对软件测试任务进行分解并制订时间表;2利用基准数据建立“工作量—工期”模型,估算合理的工期范围;3将委托方的期望工期或软件测试方初步制订的工作时间表中的工期与工期估算结果比较;如果委托方期望工期或工作时间表中的工期低于估算出的工期下限或超 出估算出 的工期上 限,则应分析 原因,必要时需对人力资源安排或项目范围进行调整,再重新估算工作量、工期,并制订新的工作时间表。

2.1.5成本估算

(1)估算直接人力成本。估算人员根据工作量估算结果和测试人员直接人力成本费率估算直接人力成本。软件测试方应优先使用本单位的直接人力成本费率数据。直接人力成本的计算宜采用以下两种方式:1根据不同类别人员的直接人力成本费率和估算工作量分别计算每类人员的直接人力成本,将各类人员的直接人力成本相加得到该项目总的直接人力成本;2根据项目平均直接人力成本费率和估算的总工作量,直接计算该项目的直接人力成本。

(2)估算直接非人力成本。估算人员根据项目情况,按照上文中的要求分项估算直接非人力成本。

(3)估算间接人力成本。估算人员根据项目情况,按照上文中的要求分项估算间接人力成本。间接人力成本应按照工作量比例分摊。

(4)估算间接非人力成本。估算人员根据项目情况,按照上文中的要求分项估算间接非人力成本。间接非人力成本应按照工作量比例分摊。

2.1.6软件测试成本确定

软件测试成本计算公式:

2.2软件测试成本数据采集

软件测试成本数据采集分两步:1对软件测试的项目规模、工作量、测试工期数据进行采集;2对软件测试成本的数据采集。

2.2.1软件测试项目规模、工作量、工期数据采集

软件测试项目规模、工作量、工期的数据采集,包括对所测软件项目的总工作量、总工期进行数据采集,还包括对项目不同活动、不同阶段的工作量、工期的数据采集。在软件测试过程中和测试结束后,负责项目度量的人员应定期或事件驱动地对所测软件项目的规模、工作量、测试工期,进行相关数据的采集[11]。

软件测试项目规模的衡量属性为项目的功能模块数。采集的项目规模数据为实际所测试的功能点数。

软件测试工作量的度量目标有两个:项目工作量分布和项目总工作量。项目工作量分布采集的数据为整个测试过程中各阶段、各活动工作量的分布情況。项目总工作量是整个软件测试项目花费的总工作量。

软件测试工期采集的数据为管理整个软件测试项目所持续的时间。

2.2.2软件测试成本数据采集

软件测试成本数据采集包括直接成本的数据采集和间接成本的数据采集。

在软件测试过程中,负责项目度量的人员应定期或事件驱动地对已发生的直接成本进行数据采集。在测试结束后,负责项目度量的人员应按照上文中的要求对各项成本分别进行数据采集。

软件测试成本所需采集的数据包括计划成本(PV)、预算成本(EV)、实际成本(AC)。

2.3软件测试成本分析

软件测试成本分析的主要内容包括成本偏差CV、成本构成、成本关键 影响因素 相关性分 析、成本性能 指数CPI分析。

在软件测试过程[12]中,项目负责人应 定期检查 实际发生成本与估算成本的偏差。数据分析的结果应与利益相关方充分沟通,并采取有效纠正措施。项目结束后,应对成本及相关数据进行分析。

3软件测试成本度量应用

软件测试成本度量采集的数据、分析的结果均可保留。在软件测试项目关闭后,度量人员应对全部的分析资料、报告和呈报结果进行总结,提取对今后工作有价值的经验教训,通过积累公司知识财富库,不断调整成本估算方法。

软件测试成本度量的数据可用于:1项目评价[13];2建立或校正成本估算模型;3组织过程改进。

4结语

软件质量度量研究分析 篇7

软件错误是软件在运行时引起软件失效的一个缺陷。软件工程中，BUG是只不符合软件需求的错误。软件错误、软件失效及软件的BUG在软件工程中是有区分的。软件失效是指软件不按用户的期望来运行，而软件错误则是隐藏在程序中的错误，有可能会被发现也有可能不被发现。

有很多不同的度量方法可以预测软件错误。如在代码开发过程中的代码静态度量方法有Halstead复杂性度量方法、McCabe复杂性度量方法等可用来检测模块的错误趋势。Fenton对用不同的语言实现同样功能的程序模块用不同静态度量方法进行了代码静态度量，结果Fenton对这种代码属性的静态度量提出了质疑。所以单纯用代码的静态属性度量是不准确的。

一个正在开发模块具有的错误趋势与在相同开发环境下和相同度量体系下的其他模块具有相似的错误趋势。因此，开发项目的早期信息或早前的工程项目的信息可以用来预测后面的软件错误趋势。虽然单独的需求度量并不是最好的错误预测方法，但它却可以增强错误预测的实施。

错误趋势预测模型应该具有有效性和准确性，因此，结合从需求文档和代码中抽取出的静态属性是比较好的度量数据来源。目前提出的预测软件错误的方法有统计方法、机器学习方法、神经网络技术和聚类技术等。在软件质量度量方面，目前利用统计和机器学习的方法对软件的需求或者是软件的代码进行度量的工作做了很多，而用聚类的方法来度量需求或软件代码静态属性的不多见。用聚类的方法结合需求和代码静态属性度量软件质量的工作目前还没人提出。软件错误趋势预测为通过软件工程进度计划和工程控制来提高软件质量提供了一条道路。

最后，本文绘制了ROC (Receiver Operator Characteristic)曲线，使用获得的数据值来比较三个模型的优劣，即静态代码度量模型，需求度量模型和需求与代码度量的组合度量模型。

1 软件错误早期预测方法

我们在需求阶段的度量数据和软件系统的代码结构是从美国航天局(NASA)的MDP (Metrics Data Program)数据仓库中收集而来的。MDP数据仓库包含了13个项目的数据，其中仅有3个项目的数据包含需求度量。这三个项目分别是CM1(用C语言编写)，包含有大约505个模块，JM1(用C++编写)，包含10878模块，PC1(用C语言编写)中包含有1107模块。CM1是美国航空航天局的航空器的仪器系统，JM1是一个实时地面系统而PC1是地球轨道卫星系统。在对从美国航空航天局项目中的数据进行收集和提炼后，上面提到的项目的需求度量和模块结构度量通过内部连接方法进行了连接。

1.1 聚类算法

聚类是一种根据某些标准来将数据划分为两个或多个群组的技术。因为在本研究中我们将数据分为两个聚类，分类的依据是看这些数据是否是无错误或有错误倾向的。所以，需要选择一个合适的将软件模块划分成缺陷模块和无缺陷模块的算法。

我们用到的聚类是利用软件度量数据中具有有限的或无错误倾向的数据去分析软件质量的一种方法。本文在预测模型中使用聚类算法中的K-Means聚类算法来预测模块中是否有错误存在。K-Means将数据分类为k组，k是一个根据数据的属性或一些性质来选定的正整数。

本文提出的软件质量预测模型试图预测软件模块具有错误倾向是否为影响软件质量的因素。识别有错误倾向的软件模块的方法有助于改进开发资源计划和进度安排，同时通过有效的错误检查能够降低开发和维护成本。这种模型可以用于不同的情形，可以预测一个模块的类(如有缺陷倾向性或无缺陷倾向性)或预测一个模块作为软件质量因素的影响(例如缺陷的数量)。然而不同的软件工程实践限制了缺陷倾向性的数据的获得。由于这种影响，监督聚类是不可能用来实现软件质量分析的。这种受限的缺陷倾向性数据可以用半监督聚类来进行分组。利用软件工程领域专家知识反复创建无缺陷聚类或错误倾向性聚类是基于聚类方案的一个约束条件。

为了预测结果，我们使用了混淆矩阵。这种混淆矩阵有四大类：真阳性(TP:True Positives)是指有缺陷的模块被正确的分类为缺陷模块。假阳性(FP:False Positives)是指无缺陷模块被错误的标记为缺陷模块。真阴性(TN:True Negatives)是指无缺陷模块被正确的标记为无缺陷，假阴性(FN:False Negatives)指那些有缺陷的模块被错误的标记为无缺陷。图1为预测结果的混淆矩阵。

利用图1，我们用下面的评估方法来获得一些有用的结果：

(1)检出率(PD)，定义为将有至少一个缺陷的模块正确的分类为缺陷模块的概率。

(2)误警率(PF)，定义为假阳性与所有没被正确检测出其性质的模块的比值，包括有缺陷的和无缺陷的模块。

根据上面定义，在软件工程实践中，我们希望PD最大的而PF最小。

1.2 ROC曲线

ROC是Receiver Operator Characteristic的缩写，中文称为接收器运作指针曲线。这项技术起初是为了增进军事雷达的敌我侦测能力而发展的。在1954年的情报理论研讨会上，哈佛大学的Meter及Middleton和密西根大学的Peterson、Birdsall及Fox同时提出了应用概算比(likelihood ratio)作为决策法则的报告。随后，这项决策法则被整合为ROC曲线。本文中的ROC曲线是在所有的实验组中PD对比PF的一个曲线图。通过对软件项目中检测出来的缺陷模块和非缺陷模块的比较来分析软件项目的成本/效益值，在这种分析中采用ROC曲线的方法是一个比较好的方法。对于不同的参数之间的比较，ROC曲线提供了更直观的显示。对于我们描述的方法的ROC曲线的示意图如图2, PD和PF值的范围从0到1。图中绘制的X轴和Y轴的取值范围都是从0到1的。在图2中绘制的点代表了预测模型中的将缺陷模块和非缺陷模块分类的可视化对比。

典型的ROC曲线是从(0, 0)开始和(1, 1)结束的凹形曲线。本文的ROC曲线分为四个不同的区域，即成本下降区域，风险下降区域，负曲线区域和无信息区域。在图2中，一条直线连接(0, 0)和(1, 1)，意味着一个分类器的性能并不比随机猜测更好。图2中的点E和F落入风险下降区域，从图可以看出，E、F点的PD与PF值都很高。这种情况对于高安全需求的系统较合适，因为这类系统更要求识别系统故障，相对来说对成本的考虑就要低一些，只要能有利于找出故障，高误报率是可以接受的。在图2中，ROC曲线上标记为A, B, C和D的点，因为低的缺陷检出率，所以几乎没有提供有关模块错误倾向性的信息。

ROC中的负曲线由低PD和高PF数据点组成。在软件工程实践中，高PD和低PF说明了模块被正确归类的比例是很高的。当PD值降低，而PF值增加时，表明模块被错误归类的概率增加。但是，这不一定是件坏事，因为在分类器否决它们的一些测试时，这可以作为它们的首选曲线。

2 结果分析

本文所提出的方法采用美国航天局的公开数据集MDP来评估软件产品的质量。我们用到了这些数据集中的CM1, JM1和PC1，因为这3个是MDP数据仓库中仅有的包含软件需求度量的项目。我们利用文献[2]中提出的模型度量需求、代码及需求和代码混合的度量。这些预测模型使用了k-means聚类方法，在软件产品中找出那些具有缺陷的软件，和那些没有缺陷的软件产品，然后在这些预测模型中找出最佳的预测模型。

在MATLAB7.4中，聚类是其统计工具包中的一个内置功能。我们在MATLAB7.4系统上利用其聚类功能对我们的方法进行了运行，其功能的参数是其默认参数。

在我们的研究中，JM1数据集作为我们的数据训练集，通过计算其特征值训练，并用训练出来的数据对评估软件的质量。PC1和CM1数据集作为测试数据，以检查其中的三个预测模型，得到一个最好的模型，用不同的聚类算法评估软件质量度量的方法，从而证实软件测试和质量保障的需求。对于比较的结果，PD值应该是最大的而PF值应该是最低的。这些值的范围从0到1。

表1显示了在JM1数据集上采用K-Means算法聚类来训练数据，并且对CM1和PC1使用了需求度量来计算它们的真阳性、真阴性、假阳性、假阴性和检出率及误警率的结果。CM1需求度量的TP值计算出来为0, TN是21, FP是0而FN是67, PD值和PF值分别都是0。类似的，对PC1采用需求度量后计算出来的TP值是0, TN是213, FP是0而FN是107, PD和PF值分别都是0。这些值显示了单个需求度量的效果并不好。表2给出的是CM1和PC1的静态代码度量的结果。CM1的代码度量的TP值是0, TN是457, FP是0, FN是48, PD和PF值分别都是0。这里PD和PF值都是0意味着这样的度量效果也不好，其值几乎和需求度量模型一样。从两个表的结果看，我们认为联合上诉两种度量方法可能效果就会比较好。

表3显示的是需求和静态代码联合度量模型的结果。其对CM1项目数据集的TP, TN, FP, FN, PD和PF值分别是66, 107, 76, 17, 0.99729和0.79518。对PC1项目数据集的TP值是115, TN值是1, FP值是361, FN值是0, PD是1和PF是0.99724。

因此，根据上面所反映的情况可以看出，通过对训练后的数据集进行静态代码度量和需求度量操作更能代表软件工程的真实情况。

源于需求度量和静态代码度量模型的PD和PF在软件容错度量方面要比先前文献中提到的方法更准确的对系统进行度量，该模型可用于对软件系统进行“故障系统”和“非故障系统”进行分类。

3 结束语

在这项研究中，我们在生命周期的早期阶段，知道错误倾向的数据情况下，结合代码中的可用数据来预测项目的错误倾向。这种预测结果能够帮助项目管理者更准确地构建项目系统，并且在预测了错误区域后能够减少测试的投入，这样这些模块可以得到妥善控制。使用这种混合度量模型的主要优点在于比较于单个的度量模型，它能够更给出更准确的度量结果，并且有助于提高软件产品的生产效率。当然，这还需要做进一步的研究，在后继的研究过程中，对于错误预测的相关影响也会逐步被发现。

参考文献

[1]FENTON N.E.and Pfleeger S.L.Software Metrics:A Rigorous and Practical Approach[M].PWS publishing Company:ITP, Boston, MA, 2nd edition, 1997.

[2]JIANG Y.CUKIC B.and Menzies T.Fault prediction using early life-cycle data[A].ISSRE2007, the18th IEEE Symposium on Software Engineering[C].IEEE Computer Society, Sweden, 2007.

[3]NASA IV&V Facility.Metric Data Program[EB/OL].Available from http://MDP.ivv.nasa.gov/.

[4]SELIYA N.KHOSHOFRAAR T.M.AND ZHONG S.Analyzing soft-ware quality with limited fault-proneness defect data[A].in pro-ceedings of the Ninth IEEE International Symposium on High As-surance System Engineering[C].Germany, 2005.