一个实际的模型测量可维护性

1、一个实际模型的测量可维护性 -初步分析报告Ilja Heitlager 软件改善小组荷兰,i.heitlagersig.nl电子邮件:Joost维瑟软件改善小组荷兰,j.vissersig.nl电子邮件:Abstract-The数量的努力,需要保持一个软件系统相关的技术素质的源代码该系统。模式模型软件产品的质量作为一种新型的可维护性道出了6个主要特征软件产品的质量,以适应、可变性,稳定、可维护性的subcharacteristics一样。值得一提的是,模式不能提供一个相互套估计可维护性措施体系的基础上的源代码。另一方面,维修性指标提出了计算一个单独的数字,表示一个系统的可维护性。在本文中,我们

2、讨论的几个问题,和我们找出数量的要求完成的一个可维护性模型是可用的。我们勾画出新的可维护性模型,大多数的这些问题,缓解,我们讨论一下我们的经验和使用系统等管理咨询活动。 1介绍。这个ISO / IEC模式1的基础上介绍了模型的软件产品质量,剖析了整体观念的品质为6个主要characteristics1:功能、可靠性、可用性,效率高、可维护性、可移植性。这些特点,27 sub-characteristics进一步划分。另外,这个标准提供了一个两厢情愿的库存的度量标准可以用来作为指标对这些特征2,3。识别和定义的软件开发过程中质量特性ISO质量模型,提供了一个有用的框架参考和标准化的术语促成交流关

3、于软件质量。这个定义度量指导推演的评价特点的基础上,对活动时间的努力相关的软件产品,如影响分析,所犯的错误修正,或者测试。不幸的是,这些上市标准是不以系统本身的预测能力和缺乏。非正式地,他们说明天天气预报今天是一样的。一般来说,提出了评价指标的可维护性特征并不是衡量的维护、如下。这个系统的代码和文档,但对履行维修活动技术人员。事实上,这个分支中给出了所谓的内部和外部的质量,而另一个细分为使用质量。也要看下面。许多软件度量已经提出的指标对于软件产品质量45。在特殊情况下,阿曼等。提出了维修性指标(MI)6,7:企图客观赋权法确定软件系统的可维护性基于状态的源代码。为基础的导弹作者在测量中进行的这

4、些结果与系统和校准的意见工程师,保持系统。这个结果系统进行拟合,以及功能推导。结果拟合函数,然后推动维修性指标产生作用。随后,小数量的改进。我们所使用的可维护性指数在我们的顾问实践8在过去的四年中,与其他许多措施,并发现一些问题提出了自己的看法。虽然我们看到一个清晰的使用为确定的可维护性源代码系统在一个或几个简单的理解度量标准,我们很难用维修性指标预期的效果。一个主要原因是一个特定的计算价值的MI不提供线索上什么特点有贡献的可维护性,价值,也在什么采取行动来改善这个值。基于限制的度量标准,如糜,我们已经形成了一个了解最少的要求这必须完成的实用型的可维护性那是建立在源代码的分析。这些要求我们已经

5、开始在头脑制定和实施了可供选择的可维护性模型。在另外一种模式,一个source-code精选集映射到。措施根据国际标准化组织(ISO)sub-characteristics模式的可维护性,下列务实映射和排名指南。本文的工作报告是初步的感觉我们可维护性模型仍在发展。在特殊情况下,调整,使模型的案例通过案例的基础。虽然如此,实用价值的典范已经证实在我们的练习,我们期望的一样进一步改进的模型不但增加了学位的细节和精度。本文是结构化如下。在第二部分,我们简述要旨这个模式,重点对软件产品的质量上的特性,可维护性。在第三节,我们再次维修性指标及其局限性我们意识到,这是通向一段IVof最小要求以一个实际的可

6、维护性模型。在特定的模式,我们会想出概况,在简化形式,在部分v第六章里,我们讨论的该模型的优点,我们素描关系实际的、更为复杂的模型,我们使用。我们分享一些经验和成果的应用在我们的管理咨询实践模型在第七章。在此次讨论有关的工作,我们总结第九节中进行 二。模式的软件。产品质量 在1991年,国际共识的术语质量特色为软件产品评估根据国际标准化组织发表(ISO)。ISO / IEC是9126:1991软件产品评估-质量他们使用特点和指南9。期间,2001年至2004年,并扩展版本由国际标准化组织(ISO)出版,它由一个国际标准(是)和三个技术报告(TR)。9126-1质量模型是1。9126-2TR2的

7、外部度量。9126-3TR3内部度量。9126-4TR使用质量指标:10国际标准躺在第一部分定义质量模型。这个技术报告包含种植业存货的措施(度量)来评价不同质量模型中定义的特点。答:在软件产品质量的观点模式区分三种不同品质模式在软件产品质量的看法。内部品质:关注系统的性能可以测量不执行它。外部品质:关注系统的性能这可以在它的执行。使用质量:关注所经历的性质(各类)用户在操作和维护该系统公司内部的质量是影响外部质量反过来影响使用质量。软件产品质量特性的四须鲃中央的质量模型的故障模式是它这些概念的内部和外部的软件产品的质量为6个主要特征,进一步subdived进入subcharacteristic

8、s共有27质量。该故障描述在图1。在这篇文章中,我们是重点可维护性特性,分为:Analysability:或容易诊断困难识别系统的部分内容被修改?多么容易可变性:做出困难或者改编而成的系统吗?稳定性:容易或困难的是保证系统一个一致的状态在修改吗?可:容易或困难的是测试该系统改造后?一致性:维修性容易或困难为使系统能符合标准和惯例对于可维护性吗?在续集里,我们将不会住在过去的subcharacteristics。第三个视图的质量,即使用质量,也不折断根据同一层次。相反,四个特点在使用过程中质量的有效性,区分。生产力、安全、满意的服务。这些特征没有细分。使用质量仍然出去的范围这篇论文的。c可维护性

9、的措施外部、内部评估办法,quality-inuse特征列在三个技术报告陪同这个标准的质量模型。对于可维护性外部质量的措施,16个特点是定义2,9内部质量的措施3。1)外部度量标准是:提出的外部通过测量性能计算的维护活动的技术人员。例如,来衡量可变的变化,时间的推移是实施建议。一个参数测量的平均时间现在的旋律,诊断之间的那一刻修正了一个缺陷。可测量,“隔”效率的建议措施,计算时间用来获得肯定已经不足修正。因此,可维护性的软件产品估计的持续时间由计时维修任务二)内部的度量标准:一些建议内部度量标准是内在的通过比较所需的特征和功能实施为止。例如,analysability、“活动录制的措施,这是被

10、定义为建议数的比值数据之间的日志实施和数量的数据,对吗规格要求。其他内部的度量标准基于测量的再次维修活动。例如,“变化影响的措施的可变性计算数字的修改和吗许多问题引起的修改。三)批判:这些建议的内部和外部的措施不是(只)基于直接观察吗软件产品,而是观察的互动产品及其环境:它的维护者,它的测试者,其管理者,或在产品的比较与它的规格,这本身就可以完全的日期,或不正确的。因此,通过观察测量可维护性一个系统的源代码,我们需要去别处。3. 重复维修性指标维修性指标6,7中提出了客观赋权法确定软件系统的可维护性基于状态所对应的源代码。基于状态所对应的源代码。analysability可变稳定性可可维护性成

11、熟容错recoverability可靠性内部和外部的质量适用性准确性互操作性安全功能,适应性,installability共生replacability可移植性收付可学习性可操作性吸引力可用性时间的行为,资源,位于效率,(MI)是一种复合数,基于几种不同的难度一个软件系统。它是基于Halstead卷(高压)。公制11,Cyclomatic复杂性(CC)12度量,平均每个模块的行代码的灵验多种用途,随意的百分比,注释行/模块(COM)。Halstead体积,反过来,是一种综合度量的基础在不同的操作符),(在来源代码。完整的拟合函数。该拟合函数的数据收集在一个大量的系统、校准和专家的意见技术人员,

12、保持他们。更高的,维护的一个系统的多被认为是。在我们的软件质量顾问练习,我们有过计算机会。可维护性指数大、多样的收藏的关键任务的软件系统。这些系统开发不同使用许多不同的技术队伍,为许多不同的目的。在此基础上的经验,我们已经确认了许多重要的局限性的语境中,心肌梗死软件质量的评价A答:根源分析自从错过是一种复合数,它是非常困难的确定什么原因为某一特定值。事实上,自拟合函数的导弹是基于统计相关性,可能就没有因果关系在所有之间这个值的度量标准和价值的导弹来自他们。接受一个数值度量我们发现,与实践者,当他们可以大大增加确定什么变化引起了系统的改变公制。当(MI)有一个特别低价值,指示低维护性,目前还不清

13、楚什么步骤被增加。B乙平均复杂度这个指标之一是用来心肌梗死的平均水平Cyclomatic复杂性。我们觉得这是根本性的缺陷号码。尤其对系统的复杂性,利用面向对象技术,每个模块将跟随一分力量法律分布。因此,平均复杂度必然会低(例如,因为所有的引领者和getters Java的系统有一个复杂的证据表明,而)维护方面的问题,将发生在少数的实用性那有异常高的复杂性。一般而言,使用通过对上的平均个人系统部件的措施倾向于面具在场的高危部分。C.计算这个Halstead体积度量,尤其是是困难的定义和计算。没有两厢情愿的定义什么是一种运算符或操作数的一种语言是这样的如Java或C #。由于这样那样的原因,Hal

14、stead体积是一种度量,不是被广泛接受的在软件吗工程领域(如见13、14因为评论)。即使一个清爽的概念界定的操作员和操作数将开放给所有主流语言Halstead度量仍将较为困难的计算。基本上,一个完整、准确的tokenization所有的程序需要进行计算,这些数字。对于某些语言是不够的,tokenization和句法局部语义分析是必需的。D评论蕴涵使用线的数目的评论作为一种度量是一个完整的代码段是更好的保持比一段代码是不记录所有。虽然这似乎是一种合乎逻辑的想法,我们发现线的数目,计数的评论,总的来说,没有关系,可维护性。经常不是简单的代码,评论已经就此发表评论出去,即使它是自然语言文字有时指早

15、期版本的代码。同样,更多的文件一个特定的一段代码可能被增加了,精确因为它比较复杂,因此更难维护。显然,错过了测量的评论,他们这一部分的可选。系统质量特性中如可变源代码的措施例如cyclomatic复杂性影响,指出可以用可引起图2。我们提出的可维护性模型系统质量特征映射定义标准ISO 9126-1到源代码的措施。第一步,在该映射的链接,这些系统特点源代码性质。第二步提供了一个测量的特性一个或更多的源代码的措施E收付-原因是没有逻辑争论的配方特定常数、变量、符号,它都是不一样的。这个公式的发生是一个合适的给定数据设置。作为一个结果,公式是很难理解和解释。为什么会有两种体积公式及措施作为参数及气体吗

16、?为什么cyclomatic复杂性呢乘以0.23吗?为什么有注释行吗出现在一个平方根与赎罪的功能吗?沟通时,关于可维护性利益相关者之间的系统,重复调用的实证研究的实验一样正当理由公式是一件令人失望的事比的启示。F控制使用的是硬,无论是在管理水平以及对技术发展水平。我们发现缺乏控制的开发者觉得他们已经结束了让他们的价值的质量(MI)不屑评估的目的。这直接影响管理验收的价值。虽然有一个测量等作为MI听候你显然更有用什么也不知道关于你的系统的状态,这种缺乏旋钮转来影响值使得它并没有人们想象的那么有用一种管理工具。四。要求和可维护性模型基于限制的度量标准,如糜,我们已经形成了一个了解最少的要求这必须完

17、成的实用型的可维护性那是建立在源代码的分析。特别是,我们想要的东西下列规定应由不同的措施在模型。应独立技术一样成为可能。结果是,他们可以应用到系统海港的各种语言和建筑。每一个步骤应该直截了当的定义那很容易计算。因此,小预付投资进行测量。每一个步骤应该简单理解和解释,同样,非技术人员和管理应便于各利益相关者之间的交流在这个系统。这个措施应该能够根源分析。通过给出清楚的线索关于因果关系code-level性质和通信质量,他们应该提供一个基础作用。在续集里,我们将讨论每个提出措施这些要求。v团体可维护性模型这些要求,我们已开始制定头脑另一种可维护性模型,其中一组精心挑选的source-code映射到

18、。措施根据国际标准化组织(ISO)sub-characteristics模式的可维护性,下列务实映射和排名指南。这决不是一个完整和成熟的模式,而工作在进步。事实上,这个模型其实这里的稳定的核心的模式演变情况案件的过程中,根据多年的软件质量咨询。进化没有停止,和调整改良,还在不断产生,新情况我们见面时,我们获得新知识,并回顾评估对各评价研究中我们完成了。在目前,我们分享当前的形势,欢迎新老客户光临惠顾反馈学术社群。就像在图二、可维护性模型系统可维护性特点,提出链接code-level措施在两个步骤。首先,这些systemlevel地图特征特性对水平的源代码,例句。摘要基于刑法典的特点,提出了一种

19、系统连接性质,如复杂的源代码。其次,每处房产的一个或多个源代码的措施下定决心,如代码复杂度是以条款cyclomatic的复杂性。下面我们将讨论这两种步骤进行更详细的讨论。A:系统特征映射到源代码的性质我们的源代码,映射这些特性是系统特点上如图3。这个观念的源代码单元中扮演着重要的角色这些特性的不同。通过一个单位,我们指的是最小的一段代码,可以执行测试。在Java或c#单元法,在一个单位是一个程序或功能。一种语言,如COBOL语言中,没有更小比一个程序。单位进一步分解等部分或者段落标签,而不是有效的代码,有足够的封装测试被执行或个别在不同的影响,源代码性能可维护性一个软件系统的特点,是这样的整体

20、卷卷源码的影响这个analysability系统。单位:复杂性的复杂性,源代码的单位影响系统的多变性和电路的可测试性。复制源码的程度:重复(也)克隆)的影响analysability叫做代码和多变性。尺寸:大小的影响,他们的analysability单位因此,可与整个系统。单元测试:程度影响的单元测试analysability、稳定、可测性的系统。这个列表的性质并不打算是完整的,或者提供船舱建造成许多不漏水的各种通信特性。相反,他们的目的是提供一个最小的、无可非议估计的主要因果关系编码性能和系统的特点。故意,我们只强调最具影响力的因果联系源代码性能和系统的特点。举例来说,没有一个关联的可并不。

21、体积意思是在不影响,而是由前者那个的影响相对较小。我们使用的名次,下面简单的规模性质和特点:+ + / + / - o / - /。现在我们将讨论了各种code-level特性进行更详细的讨论对于每个提供直接测量和指南排名。B体积它是很直观的总额系统中在任何测量的特征可维护性。一个较大的系统的要求,一般来说,一个更大的努力来维持。在特殊情况下,analysability低(高体积的原因很难理解)。1)行代码:许多不同的度量标准用于测量体积。我们可以用一个简单的线条代码度量的灵验多种用途,它们都全部行的源代码那不是评论或空白行。在这样的错误单一的编程语言,这项措施提供了充足的比较系统的理由和明确

22、的评级。例如,Java的系统KLOC 200小规模(+),而系统的13 MLOC或更多可能是非常大的()。2年经人造成相反结果功能点:无论如何,符合我方要求,我们的方法是作为语言独立的如可能,我们正确的表现力和生产率编程语言中。为了这个目的,我们利用餐桌的编程语言软件生产率研究有限责任公司(15)。一套广泛的编程这张桌子列出的语言,(我)有多少逻辑相对应一般的功能点(计划),(2)有多少功能程序员可以分,每月平均时产生使用这种语言。这可以使我们使用下列的排名计划: 因此,一个系统比男人年(我的)160非常大,是名列。对Java的系统,这个意味着130万行代码的排名,产生一种同时,此值只存在于C

23、OBOL语言MLOC 2.6%。当一个系统在各种各样的语言写的程序,我们简单翻译每个分开的近数年,人类这些在一起,并进行排序根据第2栏目。不用说,这方法。排名系统不是非常准确,但是,它已经变成了吗对于我们的目的而言,准确。事实上,我们发现了我们的排名高可用的方案;它速度快、练习重复的、正确的,explainable、技术独立。要求使根源分析不够测量的体积。当一个系统被发现的大,是测量值本身并不是马上注明原因和可能的解决方法。通过把系统成数个层次,或其他分区,它是可能的去追捕那些驱动代码的部分,膨胀。但是通常,却并非如此,过度的体积简单的结果可能会试图将太多的功能,成为一个单一的系统。三)其他体

24、积的措施:除了行代码,或男人月计算功能点,我们通过造成相反结果经常使用辅助估价。例如,一些系统是有道理的,有些估计的功能大小,通过计算数据表和田地,屏幕或输入田地、逻辑和物理文件等。我们使用相似评分方案之间的关系,这些措施。然而,通常是不容易的办法计算,他们是相当特定语言,他们并未一般体积,但是功能强大的大小。我们把它们作为次要的措施。C.每单元之复杂性这个复杂的源代码是指性质的程度内部错综复杂的源代码单位,它是组成。复杂的单位都很难理解(分析)。而难以测试,即复杂性影响到了一个单位这个analysability和测系统。1)Cyclomatic单位:从复杂的单位最小的一个系统,可被处以死刑的

25、测试独立,是有道理的cyclomatic计算复杂度在每个单元。当我们先前讨论过的、复杂遵循动力法则分布,计算平均对复杂的个体单位会给这一结果可以抚平眼角的实用性。总结复杂性的单位提供了一个复杂的整个系统。然而,这个金额已经观察到有强烈的关联性体积等措施,因此总气体,没有什么意义作为衡量16的复杂性。通过对不同的方式复杂的单位需要被发现。到一个更有意义的集合体,我们采取以下分类单元的复杂性,规定该软件工程研究所,考虑17。CC风险评估1-10简单,没有太多的风险11-20更复杂、中度风险21-50复杂、高的风险>,非常高50无从风险因此,从cyclomatic每单位的复杂性,我们能做到这一

26、点确定其风险水平。我们现在的复杂性进行单位每个风险水平数百分比行代码在单位在这一水平分类。举例来说,如果在一个逻辑体系,一万高风险单位一起金额近500名,然后总额计算的风险类别的5%。因此,我们计算相对音量系统地总结分布的代码的行了不同的风险程度。这些复杂的风险的足迹“在图4为两种不同的系统。复杂的系统风险的足迹,我们决定它使用下列图式复杂性评级。因此,被评为+ +,一个系统可以不超过25%中度风险的代码,没有任何代码或非常高高的风险。被评为+时,系统会有不超过30%的代码和中度风险、不超过5%高风险,没有代码具有很高的风险。一个系统50%以上的代码中度风险或超过15%高或超过5%,具有很高的

27、风险被评为。举例来说,这个系统的复杂性图4的将被评为,因为它既打破15%的边界对高危代码和5%的边界非常高的风险的代码。rightmost剖面的评级,导致了-因为它打破了0%,而不是5%的边界高风险的代码。我们明确的界限是基于经验。期间,本课程评价的众多的系统,这些边界原来分区分类系统的通信专家的意见。该评级方案语言独立的、容易解释和计算,对于我们的目的而言,准确。同样,通过列举了最复杂的单元,增加风险的来源、降低mainainability易追查。二)其他复杂的措施:在特定的情况下,我们使用相关配套措施的复杂性。这些包括:如fan-in结构指标,输出端操作耦合和稳定性源自这些措施。这些措施可

28、以计算出来在许多不同的方法,根据错综复杂的和一些单位,都考虑在内。我们有没有固定的、独立于语种的评分方案,这些我们雇佣他们的措施,主要是作为补充到cyclomatic复杂性。D复制重复的代码片断(克隆)是一种代码现象,出现在几乎所有的系统。虽然出现少量的重复是自然的,过量的复制是不利于其可维护性,在特定的特点,analysability和多变性18。基本上,重复做了系统的大它需要。事实上,我们经常分析系统这是(多)比我们预料的基础上他们的功能。我们已经发现,测量的代码复制出一个简单的大得多一个系统。当然,以及其他因素也做出了巨大的贡献一个系统,包括比需要的缺乏使用图书馆的功能。许多不同的技术已

29、经提出了寻找复制源码,也称为复制检测(19)-(24)。大部分的这些技术已经发展到优化之间的平衡精度高,性能和语言独立。我们已经做了几个这些尖端技术,但是我们已经决定了非常简单的方法测定代码重复。一份6行:我们块计算的代码重复是所有的代码更容易不止一次,在平等的代码块,但至少需6位线。当比较代码行,我们忽视的前导空格。所以,如果一个单是重复很多次,但是前和不同的时间,我们都后不要算为复制。如果然而,一群六线看起来比不变一个地方,我们把它作为复制。除了清除前导空格,重复测量是一种精确的字符串匹配的重复。我们的结果的精度明显低于一些更复杂的技术。然而,重复测量我们定义又是不难解释和执行,它语言是完

30、全独立的,而且非常快。在实践中,我们已经发现,准确度足够供我们目的。我们的评估方案来复制如下: 因此,一个精心设计的系统应不超过5%的代码重复。只有特别瘦系统显示复制低于3%。当复制超过20%,源代码侵蚀控制住了。重复测量允许根源分析来了最大的副本,这在一定程度上可以上市及配件在更多的重复发生的系统可以追踪下来。然而,解决问题通常包含重复保理出比简单的复制成碎片可重用的子程序。相反,一个更深层次的原因可能是礼物,如缺乏技能或支持工具、建筑或设计问题,或阻力的生产力奖励。E单元大小除了复杂性的单位,大小的单位从哪一个系统可以揭示其组成可维护性。直观、较大的单位都更加困难因为他们analysabi

31、lity保持低而又低可作为评论,有较强的统计相关性早期存在之间的大小(例如气体和cyclomatic复杂性。增值的运算单元尺寸除因此每单位的复杂性,很多可疑这个复杂的单位也将是巨大的。仍然,使用单位的大小作为衡量相辅相成的复杂性使得检测大型机组与较低的计算复杂度。在我们的经验中,许多系统包含了大量的单位,它应考虑进行评估时可维护性吗1)行代码的测量单位:尺寸,我们又说了一遍使用一个简单的代码度量。这个风险类型和评分准则相似单位的复杂性,除了那个特定的阈值是不同的。F单元测试单元测试是小程序,由开发者,为自动测试代码,一个单位的一段时间。对于许多语言,单元测试框架,可以是可得到的融入开发环境。J

32、Unit就是很好的例子为单元测试的code2,NUnit为。net的语言如C # 3。在场的一套广泛的良好的单位在一个代码库中测试有显著的正向影响可维护性。单元测试后,可提高单一按下按钮就可以执行,测试。单元测试加薪因为它们提供一个稳定、安全套房的回归为了防止网上修改时引入误差制作出来的。单元测试也有很强的documentative自然,analysability十分有利。单元测试覆盖率:1)可以测量单元测试覆盖率用专用工具,如Clover4。这些工具并没有这么做进行静态分析代码,而是一个动态分析涉及运行试验。我们的评分方案为单元测试范围如左: 因此,一个优秀的集之间的单元测试,涵盖了95所有

33、代码100%。下面是一个覆盖60%认为贫穷。单元测试覆盖率度量不履行我们的所有的一切要求。覆盖分析工具,甚至是单元测试框架,并不是所有的语言,因此没有语言独立的措施。同样,分析计算,因为没有琐碎的分析是动态的与需要一定程度的调整为每一个个体的系统。图5。测绘源代码财产成绩回到系统的分数subcharacteristics为可维护性。导出了系统级分数sub-characteristic以加权平均得分的相关(如下)。带有一个十字)代码性质。默认情况下,所有的重量是平等的。二)数量的断言的语句:高水平的单元测试报道是容易获得写单元测试的质量。一个测试,直接或间接调用的方法是,许多单位的名义上的测试,

34、但有助于高覆盖率价值。同样,一个测试中调用方法,但没有检查行为(即不含assert声明),导致没有实际测试覆盖率度量。因此,在一些情况下,意识的开发者所涉及的范围被测可能导致增加没有“真正的”进行测试。增加在这种情况下,它是必要的也测量质量的单元测试。估计单元测试的质量,我们来数一数断言的陈述。这又是一个非常简单的措施,很容易实施,理解和解释。我们目前没有固定的评分方案的地方,但仅仅使用这项措施验证范围的措施。G代码等级系统回映射个人得分后,我们抵达源代码的性质在一个得分的sub-characteristics的可维护性根据映射的聚集图3。实例这样的反向映射的source-code水平等级系统

35、级评级是在图5。基本上,到达在一个系统级分数,加权平均计算的各有关的论文根据得分的十字架标志在矩阵。这个重量都相等的默认情况下,但是不同的称重方案可以应用时适当的。当然,均可申请再次来到单一的评分为整体可维护性。为例图5,这个分数会-,可怜的可维护性。我们不属于多附加值这样一个单一的分数。更确切的说,成绩为各种sub-characteristics传达更多的信息,同时也可以追溯到一个明确的潜在code-level分数。相反,一个单独的数字,如维修性指标,这允许根源分析,指出扩散值,政府采取措施提供了依据,为提高可维护性在这个例子中,例如图5,可怜的可测性(-)可以追溯到很高的复杂性()高单位的

36、大小(-),而现在,单元测试完成。Analysability仍然是平均水平(11),尽管高复杂性(),因为这个系统体积是相当低(+)。提高可维护性,宜重构高度复杂的单位,它可以降低单位大小一样好。VI。讨论所提出的模型,介绍这里只有一个简化的子集更加复杂了模型中,事实上我们咨询实践。这个实际模型包含更多的源代码的性质、寻址等问题,运用模块化、建筑符合图书馆的框架和分离所关切的问题。同样,那不是纯粹的技术性能source-code相关考虑到,比如建立和部署过程和使用技术。这些包括测量和评定程序在check-lists及相关决策树。在两者之间的关系,提出了简化模型和实际的我们使用,所有的潜在模型是

37、选择的措施尽可能多的比赛制定的要求第四章。这些措施是容易计算和解释。他们不包含模糊公式如配件函数的可维护性指标。几乎所有的措施语言是完全独立的,保证了他们适用于系统,包括不同的技术混合物。收付的措施额定的可追溯性程序,允许根源分析问题的可维护性和提供了依据纠正行动。使用模式作为参考框架提出的模型是建立在两厢情愿的术语软件产品的质量。从讨论与开发商许多工业系统中,我们得知这个措施广为接受的。因此,应用该模型不遭受的问题确认维修性指标。它不产生一个单独的数字,它不是一种综合指标。它促进原因分析优于心肌梗死,因为它不使用平均水平。它可以很容易地解释了两个技术人员以及负责管理。它使用编号,即可很容易受

38、到改变代码。初步调查结果表明这些变化在代码使系统更加维护的,根据维护者的系统。七。一些实验结果图6。三种措施的现代化的、面向对象软件系统(Java和C #)。横轴表示程度的重复。这个垂直轴的百分比表示cyclomatic密码与复杂性20%以上。气泡的大小显示的体积。注意到系统的相媲美发现不同大小是明显的复杂性和程度的重复这个简单的办法,我们已经提出了行之有效的在练习。特别是,他们允许具有显着的甚至在系统间差异的可维护性大小,用相关技术。这一点在图6,体积、复杂性和复制绘出了对于一系列Java和c#系统。例如,对于这个两个最大程度的不同系统之间的复制16%,而所占的比例,32%的代码和cyclo

39、matic20余间复杂的变化性25%。在另一边一方面,系统可以和复杂性(4%)是不同的在不同程度之间,38%的3%。八。相关的工作,模式的软件产品的质量评价已经被称为怀疑之Al-Kilidar魏厚仁(25)。他们的批评源于企图适用的标准在一项实验pair-design有关。一个重要的批评是下列事项:“ISO / IEC模式并没有提供指导、启发式算法,法则,或其他任何方式来显示对交易的措施,如何减肥措施或即使如何简单地整理他们。”我们坚持这种批评模型,并提出了本文试图在提供这些失踪的元素。Antonellis罗卓荆。26提出的一种面向对象映射代码度量上subcharacteristics可维护性

40、根据国际标准化组织(ISO)模式。这个度量方法从度量的Chidamber和Kemerer27。这个方法包括捕获的重量为每一对度量从一个系统,sub-characteristic专家。随后,聚类分析结果进行了计算分发单位在一定数量的系统集群。这些星系团的分析提供了洞察可维护性方面存在的问题及其原因,并系统。我们目前正在调查是否该数据挖掘的方法吗我们可以补充模型。Broy李玮。m.北京:28有独立开发出一种类似模型的可维护性保养活动严格分开的事实。系统这两个行为和事实组织而成的层次树木的叶子是有关通过加权)的矩阵原子事实表明,每个原子活动的影响。这个decompositon活动是基于IEEE 12

41、19标准的维修过程中,其分解的事实已开发和工业合作伙伴。一个简化的模型,给出了全部。具体评级准则或重量。阿曼缪群。(29岁)提供了一个层次结构适度的可维护性属性的基础上,回顾35出版物。他们特殊的软件度量这棵树的树叶的结合,并提出一个公式他们成一个单一的指标。没有具体重量了列出的公式。更多的标准在试验的基础上,提出了多6,他们不仅包括源代码度量,而且信息如发生变化时,发现,与文档。九。结论和未来的工作A总结: 模式是一种良好的参照系关于软件产品质量的交流,但下降短的实际可行的方案的质量评估。在特殊情况下,根据伴随的度量标准技术报告充其量能够建立的程度一个系统的可维护性。浩瀚的文献在软件度量,另

42、一方面,提出了无数的方法提供了一种可测量软件可翻译及质量的观念。在特定的、维修性指标遭受严重不足,减轻对根源分析计算,语言的独立性、易懂性、explainability、控制。我们认为一个精心挑选的选择的措施和指南集合与评价,事实上,提供一个有用的代码度量和之间的桥梁质量特色的模式。我们已经出现过这样的一个选择,我们的品质评估软件练习,形成稳定的实际可用的核心可维护性模型。在课程的数十个软件评估项目的关键业务进行工业软件系统,该模型进行了测定和雅致。B未来的工作范顿等。30,31提出使用Baysian信仰网(圣经广播网每天24小时)在软件评价。约翰逊缪群。(32)使用BBNs延伸,叫做图表、具

43、体的影响结合模式。潜在的想法是BBNs捕捉到的因果关系,不能被捕获与传统的统计方法对软件度量。我们想了解我们的方法涉及到他们的吗我们是否能在额定BBNs模式ISO是目前发展ISO 25000系列(平方)来补充和部分取代国际标准化组织(ISO)33岁的模式、34。这个系列的第一个部分是在意料之中的要在未来两年内发表。我们正在寻找期待这样的发展,我们希望把新标准进入我们的可维护性模型。确认由于每约翰,米歇尔Kroon,Harro Stokman该软件改进组织的贡献模型的设计进行了阐述。参考1ISO国际质量体系认证,“ISO / IEC 9126-1:软件工程-产品质量-第1部分:质量模型、“瑞士日

44、内瓦,2001。2“ISO / IEC TR 9126-2:软件工程-产品质量-第二部分:外部的度量标准,“瑞士日内瓦,2003年。3“ISO / IEC TR 9126-3:软件工程-产品质量-第三部分:内部的度量标准,“瑞士日内瓦,2003年。4. . Pfleeger高手,软件度量:严格,而又实用方法。美国波士顿,麻省大学出版社,1997年:2003,第2版,修订后的印刷。5,一个框架Zuse软件测试。霍桑、台北、美国。沃尔特。1995公司,1997。6p . w .阿曼,Hagemeister期”,建设和测试多项式可维护性。”杂志预测软件系统软件卷,第3期,页。251-266,1994

45、。7m. > >粉煤灰科尔曼Lowther,p . w .阿曼,“利用度量评估软件系统的可维护性。国立成功大学电机工程研究所硕士论文,1995。电脑27岁,8号(2003年),页。44-49,1994。8.范Deursen及库佩斯,”一样,“风险评价软件,在ICSM 03:触发。智力。会议在软件维护。美国华盛顿特区:学会,2003年3月,p。385。9ISO国际质量体系认证,“ISO / IEC是模式:软件产品评估-质量特性他们使用和指导方针,“瑞士,日内瓦大学出版社,1991年。10“ISO / IEC TR 9126-4:软件工程-产品质量-第四部分:使用质量指标,在瑞士日内瓦

46、”,硕士论文,民国九十三年。11,m. h Halstead软件元素,科学。操作,编程系统。纽约,纽约:牛津大学出版社,2002年卷,第七卷。12>,“复杂性度量迈克白。”软件研究所硕士论文,第2期,第4号(2003年),页。308-320,1976年。13c·琼斯,“软件度量:好的,坏的和失踪,"电脑,第27。9号(2003年),页。98-100,1994。14Al-Qutaish Abran”,并分析和设计Halstead定义度量,”? 15)。研讨会的软件“2005年IWSM测量()。Shaker-Verlag,2005年,页。337-352。(15)软件生产率

47、研究”,编程语言写作”2006年2月2006b版本。16m. Shepperd批判”,作为一个软件度量cyclomatic复杂性,"以。英格。卷,第3期,第3卷,第2期,页。30-36,1988年。17柳中明软件工程学院",Cyclomatic软件技术的复杂性,“路线图”-/str/descriptions/cyclomatic.html。d,m. Kapser之高,“克隆”被认为是有害有害的。”工作会议上13 WCRE反向工程2006年)。电子计算机协会,2006年,页。19-28。(19)学士。贝克,“寻找near-duplication复制和大软件系统,“在WCRE 9