一种通过代码质量评估预测开源软件维护工作量的方法

摘要

本发明涉及一种通过代码质量评估预测开源软件维护工作量的方法，首先获取所有表征开源软件代码质量的指标，然后引入方差膨胀因子去除关联度较大的指标，得到可用指标集合；对用指标集合中可用指标进行线性回归分析，得到开源软件的维护工作量与可用指标之间的函数关系式，利用该关系式即可预测开源软件的维护工作量。该方法中表征开源软件代码质量的指标容易获得，预测结果精准，适合大范围推广。

说明书

技术领域

本发明涉及开源软件维护，具体涉及一种通过代码质量评估预测开源软件 维护工作量的方法。

背景技术

软件的维护工作是软件生命周期的最后阶段，也是最长的阶段。软件的维 护工作将占到整个软件生命周期花费的60％到70％。开源软件为公众提供了它 们的源代码，并且公众可以不受许可证限制的使用，修改和分发他们的源代码。

由于现代软件工程中软件维护工作占有非常重要的地位，许多人在此领域 进行了研究并创建了一系列预测模型。按照预测所用的指标不同，软件维护工 作量预测模型可分为静态预测模型和动态预测模型，静态预测模型主要有 COCOMO模型，Walston_Felix模型和Maston,Barnett和Mellichamp模型，该类 模型认为LOC和预测FP(function points)为评估软件规模和得出维护工作量的 重要指标，可作为工作量评估的推导要素。对于相同的KLOC或FP值，用不同 模型估算将得出不同的结果。主要原因是，这些模型多数都是仅根据若干应用 领域中有限个项目的经验数据推导出来的，适用范围有限。因此，必须根据当 前项目的特点选择适用的估算模型，并且根据需要适当地调整(例如，修改模 型常数)估算模型。而动态多变量模型是根据从4000多个当代软件项目中收集 的生产率数据推导出来的。该类模型把工作量看作是软件规模和开发时间这两 个变量的函数。

1、静态模型中比较著名的是在COCOMO模型的基础上Boehm对常规软件 的维护工作提出的ACT模型。在ACT模型中首次提出了软件维护工作量应该 使用(MM)人×月的方式来度量并得出了公式：

E＝ACT×2.4KLOC^1.05          (1)；

在式(1)中，E表示工作量，ACT表示系统在一年的维护工作中软件源代码 代码变更的比率。

但是ACT模型的问题在于此模型只采用变更的代码行数来度量软件维护工 作，而采用代码规模来表示软件的大小也非常不准确。此模型最大问题在于模 型本身并没有考虑到任何有关软件维护的科学属性。

Boehm BW等人在COCOMO模型的基础上又研发了COCOMO 2.0模型。 该模型可表示为：

$\mathrm{Effort}=A\times {\left[\mathrm{size}\right]}^{1.01+{\Sigma }_{i=1}^5\mathrm{SFi}}\times \underset{I=1}{\overset{17}{\Pi }}\mathrm{EMi}---\left(2\right);$

在这个模型中A表示千代码行数，功能点数或者对象个数。SF表示五个规 模度量方式包括先验经验，开发弹性度，风险解决能力，团队凝聚力和过程完 善程度。EM表示17个工作量度量方法。该模型还定义了一个新的软件项目的 规模。但是这个模型只适用于规划完善的软件项目(例如完善制度的软件公司 开发的项目)并且要评估出一个软件项目的维护工作量需要对各项指标进行大 量的采集和统计。

2、典型的动态多变量估算模型的形式如下：

E＝(LOC×B0.333/P)3×(1/t)4(13.2)          (3)；

E是以人月或人年为单位的工作量；t是以月或年为单位的项目持续时间； B是特殊技术因子，它随着对测试、质量保证、文档及管理技术的需求的增加而 缓慢增加，对于较小的程序(KLOC＝5～15)，B＝0.16；对于超过70KLOC的程 序，B＝0.39，P是生产率参数。它反映了下述因素对工作量的影响：总体过程成 熟度及管理水平；使用良好的软件工程实践的程度；使用的程序设计语言的级 别；软件环境的状态；软件项目组的技术及经验；应用系统的复杂程度。

在后来的动态模型研究中Sajid Anwar,Muhammad Ramzan,Abdul Rauf,等人 从软件架构出发评估了软件架构对于软件项目质量的影响并且将这一影响应用 于软件维护工作量的分析和估计。对软件的整个生命周期做了大量的分析从过 程管理上评估最后软件维护的工作量。这些评估方法非常有效，但是对于开源 软件则并不适用，开源软件项目并没有强力的管理约束，所以也得不到相关的 管理数据。Kun Chang Lee,Nam Yong Jo则采用贝叶斯网络的分析方法对影响软 件维护工作量的因素做出了分析并获得了较好的结果。给出了目前公认的一些 评估软件维护工作量指标的实验依据并且详细分析了它们之间的相互关联。但 是在最终的结果上文中并不能做到精确的预测工作量。

静态模型的方法体现了研究者们从软件最根本的构成，如源代码，文档等 元素中获得软件维护工作量的努力，但是静态模型的方法并不适应于维护中的 软件项目，在维护的过程中软件的所有基本构成要素都会变化而目前的静态方 法不能完全掌握这些变化对软件维护工作量构成的影响。而动态模型的方法则 体现了研究者们从软件维护人员出发，运用软件工程的思想，以管理过程的数 据对软件维护工作量做出估计和预测。但是动态模型的方法数据收集困难，对 于开源软件，管理数据根本无法收集。

发明内容

针对现有技术存在的上述问题，本发明的目的是提供一种将动静态模型相 结合，通过代码质量评估预测开源软件维护工作量的方法。

为实现上述目的，本发明采用如下技术方案：一种通过代码质量评估预测 开源软件维护工作量的方法，包括如下步骤：

S1：获取所有表征开源软件代码质量的指标，设所有指标构成指标集合， 该指标集合中共有Q个元素，q_j为指标集合的元素，表示指标集合中第j个指 标；

S2：去掉指标集合中关联度高的指标，方法如下：

1)设j＝1；

2)根据公式(4)计算指标q_j与指标集合中其他Q-1个指标的方差膨胀因 子VIF_j；

${\mathrm{VIF}}_j=\frac{1}{{\mathrm{TOL}}_j}=\frac{1}{1-R_j^2}---\left(4\right);$

$R_j=\overline{q_j}-\frac{\underset{j=1}{\overset{Q}{\Sigma }}\overline{q_j}-\overline{q_j}}{Q-1}---\left(5\right);$

其中，R_j表示第j个指标和指标集合中其余指标的关联系数，表示指标 q_j的值；

3)判断方差膨胀因子VIF_j与10之间的关系，如果VIF_j>10，则指标q_j为 待去除指标，否则为可用指标；

4)令j＝j+1；

5)如果j≤Q，则返回步骤2)，否则将所有待去除指标放入待去除指标集 合中，将所有可用指标放入可用指标集合中，并执行下一步；

6)待去除指标集合共有B个元素，b_f为待去除指标集合的元素，表示待 去除指标集中第f个待去除指标；

判断待去除指标集中的元素数量是否为0，如果为0，则执行步骤16)，否 则执行下一步；

7)令f＝1；

8)根据公式(6)计算待去除指标b_f与待去除指标集合中B-1个待去除指 标的方差膨胀因子VIF_f：

${\mathrm{VIF}}_f=\frac{1}{{\mathrm{TOL}}_f}=\frac{1}{1-R_f^2}---\left(6\right);$

$R_f=\overline{b_f}-\frac{\underset{f=1}{\overset{B}{\Sigma }}\overline{b_f}-\overline{b_f}}{B-1}---\left(7\right);$

其中，R_f表示第f个待去除指标和待去除指标集合中其余待去除指标的关 联系数，表示待去除指标b_f的值；

9)判断方差膨胀因子VIF_f与10之间的关系，如果VIF_f>10，则执行步骤 11)；否则将待去除指标b_f标为待移动，执行下一步；

10)令f＝f+1，

11)f≤Q，则返回步骤8)，否则执行下一步；

12)判断标记为待移动的待去除指标的数量是否为0，如果为0则执行步 骤15)，否则执行下一步；

13)将所有标记为待移动的待去除指标移入可用指标集合，更新待去除指 标集合和可用指标集合的元素，同时更新待去除指标集中元素的个数，执行下 一步；

14)判断当前待移除指标集合中的元素数量是否为0，如果为0，执行步骤 16)，否则返回步骤7)；

15)去除当前待去除指标集合中的所有待去除指标，并执行下一步；

16)输出当前可用指标集合；

S3：设可用指标集合共有P个元素，p_i为可用指标集合的元素，表示可 用指标集合中第i个可用指标，对可用指标集合中P个可用指标进行回归分析， 得到开源软件的维护工作量与可用指标的回归估计式：

1)获取时间段T内每个时间点t开源软件的维护工作量y_t；

2)然后以时间点t为横坐标，以开源软件的维护工作量y_t为纵坐标绘图， 得到一条折线；

3)将上述折线采用式(8)的形式表达：

y＝A₁p₁+A₂p₂+A₃p₃+...+A_kp_i+E          (8)；

4)采用线性回归方法，通过时间段T内的时间点t和时间点t对应的开源 软件的维护工作量y_t求得式(8)中的系数A₁,A₂,A₂,...,A_k和E；

S4：根据得到式(8)，在得知可用指标p_i后，即可预测该开源软件的维护 工作量y。

相对于现有技术，本发明具有如下优点：本发明提供的方法通过引入表征 代码质量的指标，并对这些指标进行筛选，然后建立指标与软件维护工作量之 间的函数关系式，从而即可利用该函数关系式精确的预测开源软件的维护工作 量。该方法中表征开源软件代码质量的指标容易获得，预测结果精准，适合大 范围推广。

附图说明

图1为本发明方法流程图。

图2为实施例中Lucene的验证结果图。

图3为实施例中openwebbeans的验证结果图。

图4为实施例中Shindig的验证结果图。

具体实施方式

下面对本发明作进一步详细说明。

参见图1，一种通过代码质量评估预测开源软件维护工作量的方法，包括如 下步骤：

S1：获取所有表征开源软件代码质量的指标，设所有指标构成指标集合， 该指标集合中共有Q个元素，q_j为指标集合的元素，表示指标集合中第j个指 标；

S2：去掉指标集合中关联度高的指标，方法如下：采用方差膨胀因子测量 指标间的多重共线性(即关联度)；

1)设j＝1；

2)根据公式(4)计算指标q_j与指标集合中其他Q-1个指标的方差膨胀因 子VIF_j；

${\mathrm{VIF}}_j=\frac{1}{{\mathrm{TOL}}_j}=\frac{1}{1-R_j^2}---\left(4\right);$

$R_j=\overline{q_j}-\frac{\underset{j=1}{\overset{Q}{\Sigma }}\overline{q_j}-\overline{q_j}}{Q-1}---\left(5\right);$

其中，R_j表示第j个指标和指标集合中其余指标的关联系数，TOL_j为容限， 表示指标q_j的值；

3)判断方差膨胀因子VIF_j与10之间的关系，如果VIF_j>10，(表明第j 个指标和其余指标的多重共线性过大)则指标q_j为待去除指标，否则为可用指 标；

4)令j＝j+1；

5)如果j≤Q，则返回步骤2)，否则将所有待去除指标放入待去除指标集 合中，将所有可用指标放入可用指标集合中，并执行下一步；

6)待去除指标集合共有B个元素，b_f为待去除指标集合的元素，表示待 去除指标集中第f个待去除指标；

判断待去除指标集中的元素数量是否为0，如果为0，则执行步骤16)，否 则执行下一步；

7)令f＝1；

8)根据公式(6)计算待去除指标b_f与待去除指标集合中B-1个待去除指 标的方差膨胀因子VIF_f：

${\mathrm{VIF}}_f=\frac{1}{{\mathrm{TOL}}_f}=\frac{1}{1-R_f^2}---\left(6\right);$

$R_f=\overline{b_f}-\frac{\underset{f=1}{\overset{B}{\Sigma }}\overline{b_f}-\overline{b_f}}{B-1}---\left(7\right);$

其中，R_f表示第f个待去除指标和待去除指标集合中其余待去除指标的关 联系数，TOL_f为容限，表示待去除指标b_f的值；

9)判断方差膨胀因子VIF_f与10之间的关系，

如果VIF_f>10，则执行步骤11)；

否则将待去除指标b_f标为待移动，执行下一步；

10)令f＝f+1，

11)f≤Q，则返回步骤8)，否则执行下一步；

12)判断标记为待移动的待去除指标的数量是否为0，如果为0则执行步 骤15)，否则执行下一步；

13)将所有标记为待移动的待去除指标移入可用指标集合，更新待去除指 标集合和可用指标集合的元素，同时更新待去除指标集中元素的个数，执行下 一步；

14)判断当前待移除指标集合中的元素数量是否为0，如果为0，执行步骤 16)，否则返回步骤7)；

15)去除当前待去除指标集合中的所有待去除指标，并执行下一步；

16)输出当前可用指标集合；

由于指标的多重共线性会严重影响回归分析的准确性，所以在进行方差膨 胀因子值验证后，去除多重共线性太大的指标之后回归分析的前置条件成立。

S3：设可用指标集合共有P个元素，p_i为可用指标集合的元素，表示可 用指标集合中第i个可用指标，对可用指标集合中P个可用指标进行回归分析， 得到开源软件的维护工作量与可用指标的回归估计式：

1)获取时间段T内每个时间点t开源软件的维护工作量y_t；(可以根据需要 设置时间点t的间隔)

一般情况下，软件维护工作量采用人*天的方式度量。但是在开源软件的维 护工作中具体的开发人员无法获取，开发人员的工作时间也无法度量。但是在 软件维护后，一定会更新软件版本，在每个版本号的日志中包含着这个版本维 护者对整个项目的变更记录。所以只要得到【Rev.(revision)修订版本】这个 指标就可以度量出开发人员的维护工作量了。

2)然后以时间点t为横坐标，以开源软件的维护工作量y_t为纵坐标绘图， 得到一条折线；

3)将上述折线采用式(8)的形式表达：

y＝A₁p₁+A₂p₂+A₃p₃+...+A_kp_i+E          (8)；

4)采用线性回归方法，通过时间段T内的时间点t和时间点t对应的开源 软件的维护工作量y_t求得式(8)中的系数A₁,A₂,A₂,...,A_k和E；

S4：根据得到式(8)，在得知可用指标p_i后，即可预测该开源软件的维护 工作量y。

实施例：作为开源项目的代表Apache基金会支持了数以百计的开源项目并 且对世界的开源软件项目做出了卓越的贡献。在Apache基金会的支持下很多项 目已经运营了数年的时间，积累了大量的源代码，源代码变更以及项目维护的 信息，并且在世界范围内有大量的优秀程序员参与这些项目的开发与维护工作。 本实施例从这些项目中选取了shindig、Lucene、以及openwebbeans.项目的相关 数据作为验证对象。其中shindig是apache的一个孵化器项目，旨在提供一个开 源的Open Social容器在2010年结束孵化转为正式一级项目，根据SVN可以查 询到这个项目转为一级项目前后的所有数据。Lucene则更是被业界评为“最近10 年Apache最有影响的项目”之一。Openwebbeans是被定义为JSR-299的Web  Beans说明实现程序。

由于指标的多重共线性会严重影响后期线性回归分析的准确性，采用方差 膨胀因子测量指标间的多重共线性，去除多重共线性太大的指标之后，线性回 归分析的前置条件成立，然后采取线性回归分析的方法取掉系数影响为0的指 标，对shindig、Lucene、以及openwebbeans三个项目的指标采用方差膨胀因子 验证方法进行分析，得出表1：

表1 表征代码质量的指标的方差膨胀因子验证表

代码实体 属性 度量标准 VIF值 LOC 代码行数 行数 Max4.92 min3.53 Duplicated 重复的代码 行数 Max5.31 min1.31 Comment lines 代码注释 行数 Max3.53 min5.36 Package 代码中的包 个数 Max685 min120 Class 代码中的类 个数 Max961 min300 Methods 代码中的方法 个数 Max361 min241 Complexity 代码的静态复杂度 个数 Max3.52 min1.22 Revision 代码变更版本 个数 Max7.66 min4.31

用方差膨胀因子(VIF)验证可以发现类的个数，包的个数，方法的个数等 都和代码行数存在多重共线性过高的问题，从表1中可看出VIF值超过10的属 于(多重共线性)关联度过大，会对后期的线性回归分析的结果造成大量误差。 而在线性回归分析时，我们可以发现这些属性的系数为0，即这些属性远不及其 他属性对代码版本的影响大。去除关联度交大的指标Package、Class和Methods， 保留LOC、Duplicated、Comment lines和Complexity，再做VIF验证这四个指 标的总体VIF为3.53小于10。最后将Revision加入指标组中做VIF验证，可以 看出在Revision这个指标和其他指标的VIF值为4653.51远远高于10。由此证 明Revision和这些指标的关联度交大，可以使用这些数据进行回归分析。

LOC(项目代码行数)：用于度量整个软件项目的规模。LOC是表示源代码 规模的重要指标。

Dup.(Duplicated)代码重复行数：所谓重复代码，是指那些彼此相似或者 完全相同的代码片段。重复代码在所有的软件中都是很常见的，它也是使得软 件的维护成本高昂的原因之一。大量的重复代码会导致运行时间的急剧增加。

Comm.(Comment lines)代码注释行数：代码注释在源代码中占有重要地位， 包括代码的可维护性，网站打开速度等。过少的代码注释会严重影响维护人员 对源代码的理解，并且由维护带来的隐藏bug也会由此增加。过多的代码有可 能影响软件的运行速度(例如页面的代码注释)。

Comp.(Complexity)项目复杂度：准确的说软件项目的复杂度应该分为结构 复杂度以及算法复杂度。一个软件项目的结构复杂度来自于组成这个项目的组 件，对应解决这个问题的可以被看作是初始的智力资源。而算法复杂度可以直 接用执行整个软件项目的时间来度量，相应解决这个问题的可以认为是初始的 系统资源。但是在维护负责人适任的情况下，维护项目使用的系统资源将会衰 减，在这种情况下算法复杂度将变得不重要。所以在实施例中，软件项目的结 构复杂度将作为主要考量指标。

Rev.(revision)修订版本：SVN里定义的项目源代码版本，在每个版本号 的日志中包含着这个版本维护者对整个项目的变更记录。开源软件的健康状况 跟开源软件的维护活跃程度相关[8],而活跃程度可以从代码版本更新得出。

根据这些指标的方差膨胀因子验证证明了选取LOC、Dup.、Comm.和Comp. 作为推导开源软件维护工作量的自变量是可行的，同时证明了表征源代码质量 的指标和源代码版本数量确实存在联系。也证明了选取源代码版本数量作为评 估开源软件维护工作量的数学合理性。

在开源软件项目的生命周期中，如果用户量的数量持续增长则会反馈回大 量的信息。开发者的数量持续增长则有助于处理用户反馈的消息。快速处理和 持续维护可以保证开源软件项目的良好运营，所以一个良好运行的开源软件项 目需要持续活跃的更新源代码版本。而且，源代码版本里存在的增量信息可以 看出开源软件的维护活跃性。并且源代码版本中包含开发人员姓名，每次提交 版本的代码变更记录，这些信息都可以反映出源代码维护的工作量。因此使用 源代码版本量评估开源软件的维护工作量有充分依据。

维护工作的最终工作成效将在源代码的基本数据中得到展示，记录这些源 代码变更数据的即是源代码版本变更数据。开源软件项目的源代码版本变更数 据相对其他管理指标更容易取得且动态变化，由此，将源代码版本数量定为开 源软件维护工作量的评估指标十分必要。

对表征源代码质量的指标采用线性回归分析来预测软件维护工作量，线性 回归分析分析多因素模型简单方便，准确的计量各个因素之间的相关程度与回 归拟合度的高低，提高预测方程式的效果，计算结果也方便对比统计等优势。 所以在这里对指标进行线性回归分析可以得出源代码指标的变化和源代码版本 数量的因果关系，并在确定系数之后可以对源代码版本的数量进行预测。

假设LOC为X₁,Comm.为X₂，Dup.为X₃，Comp.为X₄，则维护工作量y的 回归估计式可写作：

y＝AX₁+BX₂+CX3₊DX₄+E               (9)；

为了确认式(9)中的系数，本实施例以shindig、Karaf、Lucene和openwebbeans 项目为例使用2011年7月到12月的统计数据进行了回归分析，并使用2012年 3月到8月的数据做出验证，表2中列出了在不同时段收集的shindig、Lucene、 以及openwebbeans项目的部分源代码度量的指标：

表2 源代码度量的指标表

Name Date LOC Dup. Comm. Comp. Rev. Shindig 2012-05-20 51511 11017 365 12195 3985 Shindig 2012-06-02 51882 11136 365 12301 4003 Shindig 2012-06-16 51888 11142 365 12305 4020 Shindig 2012-06-24 51944 11151 365 12320 4036 Shindig 2012-07-15 51980 11170 507 12325 4054 Shindig 2012-07-29 52083 11186 507 12349 4056 Lucene 2012-05-19 78762 33921 6360 20497 5323 Lucene 2012-06-03 75515 32564 5956 19704 5412 Lucene 2012-06-16 75831 32694 5725 19802 5552 Lucene 2012-06-30 75818 32778 5705 19818 5628 openwebbeans 2012-05-20 39030 5788 2741 7687 2016 openwebbeans 2012-06-02 39062 5790 2741 7691 2018 openwebbeans 2012-06-16 39072 5795 2755 7693 2019 openwebbeans 2012-07-15 38760 5762 2519 7643 2023

由于本实验采取多元线性回归方式进行回归，检验方式最优先还是采用真 实源代码版本在每个时间节点的统计量和回归估计得出的回归估计式维护工作 量进行检验为最佳检验方法。

本试验采用三个项目从2011年5月到2012年1月的数据得出来以下回归 估计式：

Lucene:y＝-2.7614×X₁-4.4779×X₂+1.603×X₃+17.7877×X₄；          (10)；

Openwebbean:y＝0.1131×X₁+2.8619×X₂-0.1811×X₃-2.4017×X₄；      (11)；

Shindig:y＝-0.2107×X₁-0.7832×X₂+0.2308×X₃+1.917×X₄；          (12)；

根据回归估计式带入三个项目在2012年2月以后收集的指标结果进行维护 工作量增量验证。检验结果图采用了维护工作量增量在每个时间点的差值进行 做图。该做图方式可以在不损失精确度的前提下得到维护工作量增量的预测值 和真实值的直观差异。验证结果参见图2-图4：

图2-图4设定横坐标起始的时间为0，纵坐标为维护工作量增量。三张图分 别显示了三个项目2012年3月到8月的维护工作量增量的对比验证。实际误差 见表3。

表3 项目每个时间节点的维护工作量增量的误差率

表3的误差为在每次预测的维护工作量增量和真实维护工作量增量的比值。 由于源代码版本数量一直是递增的并且一般数量很大，使用预测值和真实值直 接对比只会出现很小的误差，但是这些误差就足够维护人员花费数个月去维护。 所以使用增量误差可以发现预测值的累积增量和真实数据的累积增量的差距， 从而放大误差产生的效果。在该表中可以看出误差率都在10％以下，反映出本 发明提供的算法的稳定性和准确性。

最后说明的是，以上实施例仅用以说明本发明的技术方案而非限制，尽管 参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解， 可以对本发明的技术方案进行修改或者等同替换，而不脱离本发明技术方案的 宗旨和范围，其均应涵盖在本发明的权利要求范围当中。