评估开源软件：开放源码改变质量评估方式

理论计算机科学电子笔记233（2009）5-28www.elsevier.com/locate/entcs评估开源软件乔治奥斯·古西奥斯1瓦西里奥斯·卡拉科伊达斯1帕纳焦蒂斯·卢里达斯1希腊雅典经济与商业大学管理科学与技术系Paul J. 亚当斯1Sirius Corporation Ltd.英国贝辛斯托克扬尼斯·萨莫拉达斯1 扬尼斯·斯塔梅洛斯1塞萨洛尼基亚里士多德大学信息学系希腊摘要传统上，对质量属性的研究要么在执行它的组织内部保密，要么由外部人员使用狭隘的黑箱技术进行。开源软件的出现改变了这一局面，使我们能够评估软件产品和流程，把他们交出来。 因此，存储在版本控制系统中的软件源代码和相关联的数据，错误跟踪数据库、邮件列表和wiki允许我们以透明的方式评估质量。路上了更好的是，大量的（通常是相互竞争的）开源项目使得我们有可能对比服务于同一领域的可比系统的质量。此外，通过将历史源代码快照与重大事件（如错误发现和修复）相结合，我们可以进一步挖掘问题的原因和影响。在这里，我们提出了激励的例子，工具和技术，可用于评估开源（并通过扩展也专有）软件的质量保留字：开放源码，产品质量属性，过程质量属性，SQO-OSS1这项工作是由欧洲共同体第六框架计划根据合同IST-2005-033331“开放源码软件质量观测站”资助的。1571-0661/© 2009 Elsevier B. V.根据CC BY-NC-ND许可证开放访问。doi：10.1016/j.entcs.2009.02.0586D. Spinellis等人/理论计算机科学电子笔记233（2009）5−1介绍传统上，对软件质量属性的研究要么是在执行它的组织内部进行的[4，pp. vii–viii],or it was carried out by outsiders using narrow, black-box techniques [开源软件的出现改变了这一局面[31]，使我们能够检查软件产品[27]和产生它们的过程[13]。因此，资产，如软件源代码，存储在版本控制系统中的相关数据，问题跟踪数据库，邮件列表和wiki，允许我们以透明的方式评估质量。更重要的是，由于开源软件具有相当大的经济影响[8]，并且越来越多地用于任务关键的现实世界应用程序（参见例如[5，p.313]和[17，p.81]），许多组织希望手头有关于开发过程和相应产品质量的对象度量。本文介绍了SQO-OSS的技术和研究概况，这是一个旨在建立开放源码软件质量观测站的合作研究中心。在下一节的概述之后，第3节介绍了系统2概述这项研究背后的动机来自于大约三年前，当时其作者之一（Spinellis）在他的手上发现了一台具有充足存储和互联网带宽的空闲服务器。在最近阅读了关于使用可维护性指数衡量开源质量的研究[32，24]后，他决定将其应用于FreeBSD系统10年来的发展。维修性指数（MI）是一种广泛使用的可维护性指标，ity。MI的典型值范围为200至100。较高的MI值意味着较好的可维护性。该公式及其构成系数来自大量的实证研究，公式的结果已经过测试，对实际的程序员的例如，一项研究[3]涉及惠普（HP）工程师如何比较两个类似的系统。他们主观上认为难以维护和修改的系统的MI为89，另一个在HP内部评估中因其质量而受到好评的系统的MI为123。通常情况下，我们应该为我们的特定组织和项目校准公式为了试验这个公式，Spinellis编写了一个脚本来计算目录树上的值，然后将其应用于FreeBSD系统10年来的发展快照（参见图1）。这证明了使用过程相关数据探索质量属性的价值，并启动了SQO-OSS的研究资助申请：开源软件的软件质量观测站SQO-OSS项目是一个为期两年，200人/月的欧洲研究项目。D. Spinellis等人/理论计算机科学电子笔记233（2009）57内核MI用户程序MI3585625452150094959697980001020304 05年70 5684666436260 294959697980001020304 05年Fig. 1. 在FreeBSD内核和用户程序中，程序增长和可维护性指数随时间的变化。该联盟由两个学术合作伙伴组成：雅典经济与商业大学和塞萨诺尼基亚里士多德大学，以及三个行业合作伙伴：KDAB，其员工分布在瑞典，法国，丹麦和德国，在Qt/KDE环境中执行开源和专有开发合同; ProSyst，嵌入式Java和OSGi兼容软件的领先提供商，以及Sirius Corporation，一家开源咨询公司。 参加的还有KDEe.V.，一个开源组织，为Linux和Unix工作站提供功能强大的免费图形桌面环境软件。该项目• 创建基于度量插件的架构和相应的处理引擎，• 建立新的产品和过程软件度量，SQO-OSS基础设施，• 通过Web、Web服务和Eclipse插件提供接口，开发人员可以使用这些接口来提高应用程序的质量• 公布流行开放源码软件的产品和过程度量的具体值• 建立一个基于用户指定标准的开源软件应用联盟上述目标中的每一个都不是一个独特的或创新的工具想法。 那里是几个开源工具，试图通过检查它的几个方面来评估单个软件项目的代码质量。PMD1是一个Java扫描器，试图从异常处理语句和代码问题中发现可能的错误，例如死代码或重复代码。Findbugs2执行静态分析，以揭示基于Java的程序中的错误。Checkstyle3是Java程序的编码风格检查器。Sonar4与上面的不同，它是一个Java的插件度量工具。 它以插件的形式将一组代码度量工具（如本文所述）集成到单个应用程序中，并提供总体结果。本演示文稿遵循ISO/iec9126质量模型第1http://pmd.sourceforge.net2http：//findbugs.sourceforge.net3http://checkstyle.sourceforge.net/4http://sonar.codehaus.org/维修性指标代码行数（百万）维修性指标代码行数（百万）8D. Spinellis等人/理论计算机科学电子笔记233（2009）5[12 ]第10条。一个著名的C++开源度量收集工具是加拿大国家研究委员会的ESx5除了用于独立项目的代码质量评估工具外，还有一些框架可以评估相当数量的开源项目。这些框架在网络上展示了他们的结果Ohloh6对近14000个开源项目的源代码库进行了测量这些信息包括代码行、项目使用的编程语言、开发人员贡献和使用的许可证。除了提供数字外，Ohloh还对开发状态进行了估计和陈述，例如与Ohloh类似的是Sourcikibitzer7，它分析了大约700个基于Java的开源项目。Sourcekibitzer提供了类似代码行演变和复杂性演变的报告。此外，Sourcebitzer还试图评估开发人员Scan by Coverity8是Coverity和美国国土安全部的合作项目，旨在将Coverity的商业静态分析工具应用他们在自己的网站上展示他们的结果，并根据他们的测试表现将项目分类为SQO-OSS与这些系统的一个关键区别是它能够计算和整合来自各种产品和流程相关来源的度量。这些可以包括实际的代码，版本控制系统上的操作，邮件列表中的帖子，以及系统错误数据库中的条目。因此，SQO-OSS试图将开源开发作为一个整体来考虑，而不仅仅是代码。 使用一个基于插件的系统，SQO-OSS集成了各种工具来收集测量结果。 然后，这些测量用于执行质量评估。 此外，Sq O-OSS不限于单一的编程语言，而是可以将适当的度量应用于不同语言的程序。它的目标是建立一个开源项目指标的在线数据库，结合了独立工具和上面介绍的框架的功能。不像现在的框架，SQO-OSS本身将是一个开源项目，对社区开放，对所有人免费。尝试参与其中3系统架构和实现SQO-OSS项目开发的软件一个完整的Alitheia部署包括一个数据收集系统，一个称为cruncher的计算组件，以及一个网站形式的表示层。数据收集5小时ttp：www.psmsc.com/ESx.asp6小时http：www.ohloh.net7小时http：www.sourcekibitzer.org8http://scan.coverity.comD. Spinellis等人/理论计算机科学电子笔记233（2009）59图二、Alitheia部署的架构草图系统从开放源代码项目收集原始数据，表示层将计算结果提供给用户;两者都与本文无关，整体可视为标准的三层架构。Alitheia系统的cruncher部分是一个更复杂的工件，因为它汇集了数据存储，多级缓存，元数据提取和预处理以及实际计算工作的资源管理cruncher是建立在OSGI框架（以前的开放服务网关计划）之上的.该框架管理松散耦合的组件集合，并提供生命周期和远程管理。这意味着系统的部分可以在现场选择性地更换，而无需检查系统的其余部分。它通过严格分离系统内的不同模块，为系统组件提供额外的保护。cruncher由实际的计算核心（反过来处理缓存，资源管理，调度和一些数据存储），完整Alitheia部署的其他层的连接服务和插件组成，这些插件实现了特定质量指标的计算，如本文稍后描述的CLMT或MDE图2中提供了组件的草图。cruncher的核心是OSGi的单个模块，尽管它完成了许多单独的角色。选择这种单片（本地）设计是为了简化测试和性能问题;核心的组件是紧密耦合的，我们认为它们不能或不应该单独更新。 连接层包含用于Web服务和其他连接的Java servlet容器。从OSGi框架中看到最大好处的系统部分是度量插件的集合，这些插件可以通过cruncher函数（删除度量插件的本地数据存储）和OSGi函数（例如卸载插件的代码）的组合进行扩展，禁用，删除和升级。为了说明Alitheia部署的一些组件如何工作，一起，我们走过一个典型的事件序列，触发计算和存储在cruncher。要做到这一点，我们必须从一个外部源开始：一个正在被Alitheia部署研究或监控的开源项目。假设开发人员更改了此项目的某些代码，并提交了10D. Spinellis等人/理论计算机科学电子笔记233（2009）5变化然后在Alitheia部署中发生以下事件(i) 一段时间后，数据收集组件更新了它的开源项目副本，并注意到源代码已经更改。(ii) 数据收集组件更新来自数据源的原始数据，并连接到cruncher以通知它原始数据的变化(iii) 处理器从数据收集组件检索原始数据，对其进行分析，并将提取和预处理的元数据存储在本地。(iv) cruncher决定哪些度量插件应该对新数据起作用。这些插件中的每一个都被要求计算原始数据中的变化的结果。(v) cruncher的调度器部分处理资源和CPU分配给随后的计算作业。(vi) 每个度量插件都进行计算并存储其结果。一旦核心激活了用于计算的度量插件，主服务器和从服务器的角色就颠倒了：度量插件开始向核心查询服务。 核心提供了两个级别的数据访问，每个级别都有自己的缓存方案，通过瘦数据服务层和胖数据服务层。 网络可以使用任何一层，建议使用胖层，因为它比瘦层提供更多的处理和缓存数据。瘦数据层（TDS，之所以这么叫是因为使用它进行数据检索是一个令人厌烦的过程）向客户端提供原始项目数据（例如，度量插件）。 原始数据包括项目源代码，作为单独的文件内容和源代码签出，项目源代码历史，RFc822格式的邮件消息和错误数据。TDS管理对数据的访问，并进行资源管理，这样原始数据请求就不会压倒cruncher（例如，通过同时请求对该项目的所有830，000个修订版的KDEFat数据系统（FDS）处理关于单个项目的已处理元数据，否则这些元数据将通过TDS检索;对于邮件消息，我们可以考虑发送者、接收者、主题等可以单独查询的元数据位。FDS还执行聚合并允许更高级别的搜索：“哪些邮件消息是上周二发送的或者“对该消息有什么回复”。FDS使用数据库存储器为cruncher存储元数据。 我们假设元数据比原始项目数据更小，使用更简单。FDS的另一个特性是产生这对于在多个数据类型上操作的度量或试图度量项目过程的某个方面而不仅仅是产品的度量是有价值的从指标插件的角度来看-一旦该指标被激活，做一个具体的测量-Alitheia核心的架构是颠倒的：FDS是要使用的主要服务，直接使用元数据数据库D. Spinellis等人/理论计算机科学电子笔记233（2009）511调度器DB指标激活器FDS更新器LoC指标OSGi调度器DB指标激活器FDS更新器LoC指标OSGi调度器DB指标激活器FDS更新器LoC指标OSGi调度器DB指标激活器FDS更新器LoC指标OSGiruntime（ProjectFile[]）enqueue（MetricJob（ProjectFile））(a) 更新程序通知指标激活器（b）指标激活器将计算作业入队run（ProjectFile）getFile（ProjectFile）（c）执行作业（d）指标从FDS调度器DB指标激活器FDS更新器LoC指标OSGiaddRecord（项目文件）(f)将结果存储图三. 指标激活和处理如果FDSAPI不充足，并且TDS将用于低级数据传输，则可用;度量总的来说，度量可以将Alitheia部署的其余部分视为精心设计的多级缓存机制，其中来自度量所研究的开源项目的远程数据由数据收集子系统镜像（减少延迟）。原始数据访问），然后复制到处理器以通过TDS进行立即研究（进一步减少数据访问时间，但是如果需要的话，仍然需要处理以获得公共元数据），并且以预摘要的形式存储在FDS中（进一步减少获得公共元数据的时间）。再次翻转视图并检查接口，提供给cruncher，我们看到这个接口有三个功能领域：生命周期管理，测量（执行测量并在通信和表示层之后获得结果），度量配置和元数据。OSGI框架在加载和卸载度量插件时会调用数据库管理，这是保持数据库干净所必需的。它遵循安装、更新和删除的标准模式。 度量配置和元数据是一种简单的键和值接口。度量插件实现了一个或多个度量，这些度量对所研究的开源项目中的一种或多种变化感兴趣。我们使用Java图3展示了为一个文件数组计算一个简单的行计数度量所需的步骤。更新器组件从外部通知镜像项目资产的更新已经发生;然后它继续增量地处理资产元数据，同时记录已经更改的确切资源。然后它通过12D. Spinellis等人/理论计算机科学电子笔记233（2009）5OSGi客户端Web服务插件管理DBLoC指标OSGi客户端Web服务插件管理DBLoC指标OSGiWeb服务插件管理DBLoC指标getResult（指标，文件）getMetricRef（指标）(a)客户端请求文件的度量结果（b）Web服务获取度量接口DB插件adminOSGiWeb服务LoC指标OSGiWeb服务插件管理DBLoC指标getResult（文件）findResultObject（文件）(c)Web服务询问度量（d）度量检索结果结果(e)返回结果见图4。 结果检索将相应的信息发送给度量激活器（a）。指标激活器为每个更改的资产创建一个作业，并调用调度程序将作业入队（b）.当线程可用时，调度程序运行作业。作业本身本质上是用适当的参数（c）调用度量有了这个引用，度量可以查询FDS组件，从原始数据源检索文件最后，对文件的行数进行计数，并将结果存储在数据库中（e）。最简单的结果检索场景如图4所示。客户端向Web服务组件请求由特定文件（a）上的度量计算的度量。 由于每个指标可以以任意方式在系统的数据库中存储结果，不可能使用通用的数据检索机制来搜索度量结果;相反，每个插件都提供自己的结果检索功能。因此，Web服务必须调用插件管理员来获取对实现特定度量（b）的插件接口的引用，然后查询插件本身对于特定的度量的结果（c）。插件代码在数据库（d）中搜索结果，并将其返回给Web服务，Web服务将其封装在SOAP消息中并将其返回给客户端（E）。测量检索会引起并发症。有些测量可能不例如，当一个大型项目被添加时，可能需要一些时间才能完成所有测量，或者我们可能会忽略“旧”数据的测量，直到有人表示对它们感兴趣。 我们可以区分响应时间很重要的情况;如果表示层中的用户界面（通过通信层和核心）请求特定的测量，则快速响应很重要：如果我们知道测量值，则提供测量值，否则提供D. Spinellis等人/理论计算机科学电子笔记233（2009）5133002502001501005000 4812 16 20时间（UTC）图五、在FreeBSD系统中进行全天候的全球开发测量，以便下次返回更好的结果）。在其他情况下，响应时间并不重要。假设我们有一个度量，它计算系统中其他两个度量之间的比率（例如，文件中注释的百分比，通过将注释行数除以总行数）。在这里，计算必须同时具有这两个值才能继续。我们介绍了两种检索度量的方法：阻塞方法（等待度量可用）和非阻塞方法（返回“I don't know”值）。非阻塞复合测量将对其成分使用非阻塞检索，而阻塞复合测量将使用阻塞检索。 返回“I don't know”的非阻塞查询将启动 测量过程，以便将来的查询将收到一个值。这种方法巧妙地解决了表示层尚不可用的度量问题以及复合度量的问题。因此，可以从几个方面来看待Alitheia系统的架构：作为标准的三层架构;作为将数据获取到指标的多级缓存方案;作为指标的存储提供者，以及作为响应用户查询的结果数据库4开源软件质量本节列出了一些激励性的例子，说明产品和过程度量如何可以提供对软件质量的洞察4.1全球软件开发质量在开发SQO-OSS基础设施之前的一项试点研究[28]使用了来自FreeBSD操作系统的数据资产来检查全球开发的程度及其对生产力和质量的影响。具体来说，我们使用了开发人员位置数据、配置管理存储库和问题数据库中的记录。全球软件开发的一个经常被宣称的优势是能够在连续的24小时周期内全天候开发软件。在图5中，我们可以看到这个目标确实在FreeBSD项目中实现了。计的十LOC101 102 103 104 10514D. Spinellis等人/理论计算机科学电子笔记233（2009）5多年来，FreeBSD开发者平均每天每小时提交177行代码;这个数字在最小116行（02：00UTC）和最大285行（03：00UTC）之间波动。该研究还考察了大量（地理上分散的）委员会成员如何影响所产生代码的质量。如果软件研究的目的我们选择检查对FreeBSD代码风格指南的遵守情况[7]作为整体代码质量的代表。我们选择这个度量标准是因为我们可以通过格式化每个源代码文件， 根据FreeBSD风格指南配置 将改变的行的百分比（实际文件和格式化文件之间的最小差异集的大小）。此外，通过让cVS生成源代码文件的列表，每行都用最后修改它的作者的名字进行注释，我们可以计算出在该文件上工作的开发人员的数量。有了这两个测量值，我们使用皮尔逊积差法来检验两者之间的相关性。 11，040对测量值的相关系数在0.03和0.07之间的95%置信区间中为0.05。因此，我们看到，在FreeBSD的例子中，地理上分散的程序员（一个过程属性）参与代码开发并没有影响所产生代码的质量（一个产品属性）。最后，我们检查了不同开发者的文件的全球开发是否与提交给它的问题报告数量的增加有关。这种相关性可能表明FreeBSD项目中的全球开发导致代码中错误数量的增加，例如，由于不同开发者之间的沟通问题。 尽管问题报告被保存在一个与FreeBSD配置管理系统不同的数据库，已纠正的问题通常通过引用相应的问题报告（PR）在cVS因为严重的问题报告根据定义迟早会被纠正，我们可以通过将标记有PR号的提交消息的数量除以文件提交的总数来然后，我们可以检查该比率与向相应文件提交代码的不同开发人员数量的相关性。我们收集了33，392个源代码文件，457，481个提交消息和12，505个 PR。平均而言，每个文件与13.7个提交，0.37个PR和4.2个不同的开发人员相关。pr密度和提交者数量之间的双边Pearson0.06 0.08。因此，来自FreeBSD项目的数据并不支持全球软件开发与更高的bug密度相关D. Spinellis等人/理论计算机科学电子笔记233（2009）515.Σ产生的代码中4.2平均开发人员参与度敏捷开发方法背后的原则和开源社区中的常见实践是非常不同的。 近年来，人们对这些问题的兴趣有所增加，目的是发现和通报具有兼容性的共同做法的领域。在[1]中，我们认为可以量化开源项目所显示的敏捷性水平。敏捷性的一个指标，平均开发人员参与度（MDE）指标，通过对公共项目数据的分析进行了介绍和测试。从两个存储库（KDE和SourceForge）中取样的项目进行了研究， 制定零假设：来自两个样本的项目显示出相似的MDE水平。由于开发人员是自由软件社区中的有限资源，因此自由软件项目吸引他们的开发人员资源以保持他们的兴趣是很重要的。为此，衡量参与度的MDE在数学上，这可以描述为：（一） 其中：de=ni=1发展（活动）发展（总数）in• dev（active）是在时间段i中活跃的（不同的）开发者的数量。• dev（total）是在0.. I.• n是项目评估的时间段数。对于这项研究，这些是一周的时间这种方法最初的缺点是dev（total）很难定义。 作为第一次尝试，这只是项目Subversion存储库中的帐户数量。然而，这是一种幼稚的方法，因为即使开发人员离开项目，帐户的详细信息仍然保留在Subversion存储库中.为了使这种测量更准确，我们引入了开发人员的“宽限期”。这是一段开发人员不活跃的时期，我们仍然认为开发人员是一部分开发（总） 开发人员参与项目的时间越长，我们允许他们的宽限期延长。一个KDE项目历史的MDE第六章此图清楚地显示了所有Open Software项目共有的一些功能• MDE在数学上必须从1开始。也就是说，至少有一个开发人员在项目的第一周内是活跃的，并且当时是项目中唯一的开发人员。简而言之，项目成立。• 项目开始时的MDE显示出波动。这是由dev（active）的变化引起的，而dev（total）和n都很低。Σ16D. Spinellis等人/理论计算机科学电子笔记233（2009）5≤−10.950.90.850.80.750 100 200 300 400 500 600时间（月）见图6。 MDEfor theKDE项目• 波动时期之后是一个更稳定的时期图6的一个独特元素是，项目的稳定阶段没有显示出特定的趋势（向上或向下）。 相反，该项目在近十年的时间里成功地保持了近80%的活动水平我们将MDE应用于40个开源项目的整个历史，其中20个来自KDE，20个来自SourceForge.net。然后，我们使用Wilcoxon测试来表明，在其生命周期中，SourceForge的项目显示出比KDE项目更高的MDE然而，这与仅1周的n为了抵消这一点，我们最终制作了一个“e-排序”分数。为了做到这一点，我们首先计算项目生命周期内的平均MDE，方法是取项目生命周期内每周的MDEe的平均得分是通过将MDE的平均得分乘以n的最大值（项目的周数）来计算通过比较新的排序值，我们能够重新应用Wilcoxon检验，得出W=374，p 2的结果。第405集第6集。这让我们有95%的把握说，随着时间的推移，一个随机选择的KDE将比一个随机选择的SourceForge项目显示出更大的开发人员参与度，因此代码库将封装更多的开发人员。MDE平均开发人员参与度D. Spinellis等人/理论计算机科学电子笔记233（2009）517Metric Id Metric NameSqO-OSS v0.8NOPA公共属性数·没有c儿童数量·编辑继承树A、c、d、e、NPM公共方法类的RFc响应罗克姆 勒克姆代码行·评论的线条方法缺乏凝聚力NOPRM受保护方法的数量·没有cLcBOWMc班级数量·对象类每个类的加权方法·表1按cLMT列出的支持指标4.3跨语言度量工具跨语言度量工具（CLMT）计算软件复杂性度量，多种编程语言。 cLMT通过将每个编程语言转换为中间XML表示（IXR）。cLMT接受描述特定度量计算任务的XML解析源文件并生成IXR这些指标是通过对IXR的一系列查询计算出来的。 结果以文本输出形式呈现或者作为XML结构化文档。表1列出了首个CLMT版本将支持的指标。在第三列中，我们显示了当前版本中已经支持的指标虽然cLMT现在可以使用Java编程语言，但下一个版本计划支持C和C++;事实上，支持不同的编程语言是主要的设计要求之一CLMT作为独立的应用程序独立于SQO-OSS而存在，但是也已经与后者集成，尽管这种集成并不简单。在图7中，我们将CLMT体系结构描述为一个sqO-OSS插件。4.4不需要的头文件包含指令许多广泛使用的编程语言使用词法包含文件作为共享和封装声明、定义、代码和数据的一种方式。 随着代码的发展，包含在编译单元中的文件通常不再需要，但是定位和删除它们是一个随意的操作，因此被忽略了。不必要的包含文件对项目的质量是有害的，因为它们会导致命名空间污染，引入虚假的依赖关系，并增加编译时间。对包含文件进行推理的困难主要源于这样一个事实，即宏的定义和使用使范围和标识符边界的概念变得复杂。通过定义四个连续细化的标识符等价类，我们可以准确地推导出标识符之间的依赖关系[26]。在包含文件之间的关系图上映射这些依赖关系可以18D. Spinellis等人/理论计算机科学电子笔记233（2009）5度量插件SQO-OSS交叉-语言度量插件接受源代码输入（Java、C和C++）转换为IXR（中间XML代表）计算代码并存储它们见图7。 cLMT架构10000100010010101 10 100 1000 1000项目规模（千万亿美元-对数规模）图八、 不需要在各种规模的项目中包含指令然后用于确定在给定编译单元中不需要的包含文件[29]。具体地说，只有在以下情况下才需要头文件：• 包含一个标识符的定义• 包括所需的其他文件;或• 将代码或数据提供给包含它的编译单元不需要的包含指令（对数标度）D. Spinellis等人/理论计算机科学电子笔记233（2009）519我们在32个中型和大型开源项目上测试了我们的方法。这些问题是：Apachehttpd 1.3.27，Lucent的awk（2003年3月14日），bash 3.1，c vs 1.11.22，Emacs 22.1，自由bsd head分支的内核（9月9日），2006 lint配置处理的i386，amd 64 ， 和 spar c64 架 构 ， gdb 6.7 ， Ghostscript 7.05 ， gnuplot 4.2.2 ， at tGraphViz 2.16，为x86 - 64处理的Linux内核2.6.18.8 - 0.5的默认配置（amd 64）体系结构，2007年8月8日发布的Solaris内核，适用于Sun4v Sun4u和spar c体系结构，针对i386和amd 64体系结构处理的Microsoft Windows Research Kernel1.2、 Perl 5.8.8、 Postgre s q 18.2.5、 Xen 3.1.0， 以及程 序bind、 ed、 lex、mail、make的版本，ntpd、nvi、pax、pppd、routed、sendmail、tcpdump、tcsh、window、xlint和zsh随Free bsd 6.2发布。&FreeBSD程序在运行于i386处理器架构上的FreeBSD 6.2下处理，而其余未指定的程序则在运行于AMD64处理器架构上的openSUSE为了方便起见，我们通过寻找有代表性的、广泛使用的、用C编写的、可以独立编译的大型系统来处理的源代码大小为1420万行代码。结果总结见图8。正如我们所看到的，不需要的头文件对于小于20KLOc的项目来说很少是一个问题，但是随着项目规模的增加，它就成为一个(The图表4.5开发人员贡献在软件工程中，贡献评估需要衡量一个人对软件项目开发的代码行或功能点的贡献。然而，在最近几年，转向更敏捷的开发实践和软件和项目管理工具的扩散已经减少了经典的软件评估模型的评估能力。今天的软件开发人员不仅需要编写代码，还需要与同事进行有效的沟通，并使用各种工具来生成和修改用最少的输入来编写代码在[9]中，我们提出了一个模型，该模型利用可公开访问的软件存储库的可用性来提取过程数据，并将它们组合在单个贡献因子中。表2给出了我们的模型评估的项目资产上的操作的概述。每种操作类型的操作数是按开发人员计算的，而权重则应用于每个操作，具体取决于此操作在项目数组中出现的频率。然后将提取的贡献因子与开发人员4.6重构对软件质量的影响重构被认为是改造软件以提高其质量的最重要手段之一。 它的目的是降低复杂性，在设计和源代码级别的系统，使其能够进一步发展，在低成本20D. Spinellis等人/理论计算机科学电子笔记233（2009）5资产操作类型代码和文档存储库邮件列表-论坛添加好/坏质量P/N的代码行提交新的源文件或目录P提交生成/关闭错误的代码N/P添加/更改代码文档P提交补丁到代码风格P在一次提交中提交超过X个文件N提交文档文件P提交翻译文件P提交二进制文件N使用空提交注释N提交Commit comment that awards a pointy hat P Commitcomment that includes a bug report num P第一次回复线程P创建一个新的线程P参加一个网络战争N关闭延迟线程P错误数据库关闭一个错误报告确认/无效的错误P/N关闭一个bug，然后重新打开评论一个错误报告P创建一个新的wiki页面更新wiki页面P从documentation/mail file链接wiki页面经常参与IRcP迅速回答直接问题P表2项目资源和可以对它们执行的操作。“类型”列表示操作具有正面（P）还是负面（N）影响。图第九章用于评估重构效果的过程通过确保开发人员的生产力并减少设计错误的空间来实现这种方式在这里，我们感兴趣的是重构对知名开源项目质量的影响，正如我们在[34]中报告的研究中所提出的那样大多数研究软件质量和度量之间的关系，如[35，14，33]，或者重构和软件质量，并没有将系统的发展与度量测量的变化联系起来。我们试图展示重构在流行的开源软件项目中是如何影响度量的。在应用重构转换之前和之后，测量了各种已建立的软件质量度量。源代码控制系统历史被用作信息源，以检测后续修订之间执行的重构这项研究的一个令人惊讶的发现是，重构对4个OSS项目样本的软件质量度量值有负面影响。 具体来说，重构似乎导致了LcOM等指标的显著增加D. Spinellis等人/理论计算机科学电子笔记233（2009）521数据集大小k r2in/outin/outJ2 SE SDK13,0552.09/3.12.99/.86Eclipse22,0012.02/3.15.99/.87OpenO服务3,0191.93/2.87.99/.94BEAWebLogic80,0952.01/3.52.99/.86c盘包装27,8951.93/3.70.98/.95Linux库4,0471.68/2.56.92/.62自由BSD库2,6821.68/2.56.91/.58MS-Windows二进制文件1,3551.66/3.14.98/.76免费的BSD端口，库和部门5,1041.75/2.97.94/.76免费的BSD端口，构建deps8,4941.82/3.50.99/.98免费的BSD端口，运行时deps7,8161.96/3.18.99/.99TE X1,3642.00/2.84.91/.85META字体1,1891.94/2.85.96/.85Ruby6032.62/3.14.97/.95TE X的错误1,2293.36.94Linux系统调用（242）3,9081.40.89Linux C库函数（135）3,9081.37.84免费BSD系统调用（295）3,1031.59.81免费BSDC库函数（135）3,1031.22.80表3软件幂律。(Lack方法中的内聚，表示方法的相似性）、Ca（一致耦合，依赖于类的其他包的数量）和RFc（类的响应，类本身的方法和它调用的所有其他方法的数量之和），表明它导致类变得不那么一致因为他们被赋予了更多的责任。 同样的原则似乎也适用于在程序系统中也是如此，在这种情况下，效应被捕获为增加复杂度指标。由于人们普遍认为所使用的度量标准实际上可以指示系统的质量，因此这些结果表明，要么重构过程并不总是以可测量的方式提高系统的质量，要么开发人员仍然没有设法有效地使用重构作为提高软件质量的一种手段。换句话说，这些结果可能表明重构没有以提高所研究项目质量的方式使用 或者软件质量度量不是衡量重构所带来的质量改进的最佳方法。4.7软件中的幂律幂律作为一种描述性工具的概念已经存在了一个多世纪[20]。在这一时期，幂律以不同的形式出现在不同的背景中。在数学上，幂律是一种概率分布函数，其中随机变量取某个值的概率与该值的负幂成(2)P（X=x）<$cx−k 其中c>0，k> 022D. Spinellis等人/理论计算机科学电子笔记233（2009）5k−1大型开源软件系统的可用性使我们能够研究其模块的无标度网络的存在性[16]。我们选择了不同大小和功能的模块对于我们的目的，连接模块的链接由它们的依赖关系给出。对于两个模A和B，当B依赖于A时，我们增加一个从B到A的有向链路。这就产生了一个有向图。我们探索传入链接和传出链接的结构请注意，测量扇入和扇出并不新鲜，并且已被用作过程复杂性的度量[11]。在这里，我们对测量复杂性不感兴趣，而是想看看不同抽象级别的传入和传出链接是否显示出相似的模式。这样的模式然后可以与各种质量度量相关。我们的调查结果摘要见表3。 在每一行中，我们列出了 节点的数量、传入链路和传出链路的指数（如果适用）以及相应的相关系数。 在我们的数据中观察到的长而胖的尾巴影响了软件工程的几个方面，例如质量，设计，重用和优化。根据我们的研究结果，我们建议考虑到电力法律存在于软件中，以集中开发工作，并节省资源的质量保证任务。即使作为软件开发人员，我们可能无法在系统中定位随机选择模块，我们可以预期大约百分之一的依赖项不会导致所选模块中的bug传播。然而，如果我们专注于系统中的顶部（就依赖模块而言）百分之一的模块，我们可以避免错误传播到多达θ个其他依赖模块，其中θ= 1 −1（详细信息参见[16]）-这是一个显著的改进。例如，如果我们考虑到bug的无标度分布，那么beta测试的成功和失败就可以得到解释; beta测试人员将很快发现少量的缺陷，这些缺陷占可以发现的缺陷的很大比例;在与此同时，总会有其他的影响，与一个低得多的概率， 在测试中发现，这将继续折磨不幸的用户在生产过程中。然而，尽管有最好的电子竞技，一个系统仍然可能失败。面向恢复的计算将此视为生活中的事实，并要求在各种抽象级别上识别适合快速恢复的系统[2]。这表明中心模块可能是合适的候选者。4.8开源软件的质量模型背景下SqO-OSS 我们定义了一个软件质量评估，基于定义和衡量软件质量的软件模型[15]。这种特殊的模式旨在捕捉开源软件开发过程的特殊性所产生的特殊性。此外，它关注源代码和项目周围的社区该模型在[23]中给出。模型构建过程遵循GqM[25]方法。 结果是一个层次树视图的质量在-D. Spinellis等人/理论计算机科学电子笔记233（2009）523社区品质SQO-OSS质量特性产品（代码）质量测试性稳定性维护性有效性成熟可靠性可变性分析性见图10。 服务质量模型100 70 3608050604040302020102.521.510.50FreeBSDLinuxSolarisWindows0FreeBSDLinux0Solaris Windows图十一岁文件和全局作用域上的公共耦合（左）