金融开源软件成熟度的可变权重模型和改进方法

蔡一晓 吴承荣

(复旦大学计算机科学技术学院 上海 200433)

0 引 言

随着开源软件行业的不断成熟和完善，地位越来越高，很多公司考虑在自己的系统中使用特定的开源软件，而在市场中往往存在几款从功能等方面比较接近的开源软件，需要一套比较完整的评测流程来帮助使用者决定具体使用哪一款开源软件。

现在通用的包括OMM、国家软件质量评估标准等软件成熟度评估体系考虑了软件的一部分具体的评测标准。在这一个基础上再结合金融行业的具体需求，就可以建立一套比较完善的软件成熟度评估体系。

为了全面评价金融行业开源软件的质量及其应用的成熟度，帮助软件需求方从众多开源软件中选择合适的软件，金融行业开源软件成熟度评测体系将围绕金融业务的实际需求，对开源软件的选型、质量检测、成熟度评估以及软件供应商的评测等进行全方位的评估。

在金融行业开源软件成熟度评估体系中我们已经建立了比较详尽的评测条目，在已有具体的评测条目的基础上，本文将根据已经采集到的数据来量化评估金融行业开源软件的具体特性，建立具体的数学模型将采集到的数据客观化。

同时，本文也将讨论这些数据的采集方法，做到将现在的金融开源软件的评测模型运用到实际的评测流程当中去，使得企业可以使用我们的模型和方法来判断在具体的环境中应该选择哪一款开源软件。

1 金融开源软件成熟度整体模型

1.1 整体模型的流程和方法

一个完整的评测一款开源软件的流程包括建立配套的测评环境、定义具体的评估流程、质量属性和评分标准。属性评测取得相对应的值，以及根据具体的模型来计算结果。图1是软件成熟度测试的大致流程。

图1 开源软件成熟度评测的流程

在确定了具体的软件类别之后，需要我们考虑的是如何去定义评估流程，设定具体的评估条件。评估条件是指软件在成熟度评估中某一方面的具体特征，它反映该软件在这一评估点上表现的好坏程度，对所有评估条件的综合考虑即得到软件成熟度的评价值。

评估条件是建立一个评测模型的基础，评估条件选取得是否合适、得当，对整个评估结果的准确性、公正性会造成非常大的影响。评估条件分为定性指标和定量指标两种，理论上讲，定量指标能够更科学客观地反映软件的质量特征，但由于并非所有的质量特征都能用定量指标描述，因此不可避免地要采用一些定性指标。一般在选取评估条件时应该遵循如下的几条原则包括：典型性、简明性、完备性和客观性。

同时还要结合我们的主题：金融开源软件的成熟度评估，在选取评估条件时候也要着重去考虑金融和开源两个重要的点。

1.2 软件质量评估标准

结合国家软件质量评估标准分析开源软件与传统软件的通用评估标准。该步骤的重点是从各个角度对软件质量进行评价，例如软件的功能、效率和稳定性等。

国家软件质量评估标准中定义的评估条件涵盖一般软件质量的各个方面，并且具有较强的权威性，如表1所示。

其次，归纳和整理符合开源软件特性的评估条件。开源软件从开发、运营的管理到后续服务支持等都有其独特性，除了软件自身的，这些开源特性也是软件选型时的考察重点。经过从五种国际流行的开源软件评估模型(OSMM Capgemini，OSMM Navica、QSOS、OpenBRR、OMM)的考察，从中选取了较为成熟的三种模型QSOS、OpenBRR和OMM作为参考依据，从而保证整体模型的评估条件有充分的理论支撑。

然后，围绕金融行业解决方案的特点进一步调整和补充现有评估条件。该步骤根据金融行业解决方案的特点分析各评估条件的重要性，按照评估条件的选取原则和标准对上述过程中得到的评估条件进行补充和整合。

按照以上的标准进行整体模型评估条件的选择，确定金融开源软件的成熟度评估标准，并在这个基础上确定每一条大的标准的子属性。

1.3 基于开源和金融方向的评估条件补充

1.3.1 基于开源方向的评估标准

开源软件从开发、运营的管理到后续服务支持等都有其独特性，在选取开源软件成熟度整体模型的评估条件时需要充分考虑这些特性。基于此，我们在现有的评估模型中加入了如下的几条具体一级的属性，二级要素的选取在这里不展开讲述。最后选取的评估条件见表2。

表2 符合开源软件特性的评估条件

1.3.2 基于金融行业的评估标准

金融行业的组织体系和业务性质都有其自身的特点。在构建金融行业开源软件成熟度模型时，除了考虑开源软件与传统软件的通用评估项和开源软件的特性评估项，针对金融行业解决方案的自身特点调整和补充现有评估条件也是十分必要的。对此，我们在整体模型中加入了安全性、服务支持、可靠性等3个具体的评测条目，同样，这里也不展开二级要素。

1.4 评估条件整合

基于以上的工作，我们可以建立具体的金融开源软件成熟度评估体系的一级条目，在前期的工作中也确定了每一项一级要素下面的二级条目，从而得到了开源软件整体模型的评估条件和子属性，见表3。

续表3

2 评估条件的权重和数学建模

为了具体地去测评某一款开源软件的各项属性，量化评价。首先我们需要设计各个子属性的权重，对于11个一级要素和相对应的二级要素，量化相对应的表现，并根据重要性程度进行权重的建立。

2.1 权重和评分的设计标准

在有评分的项目评估规范中，我们需要为属性定义他们的权重标准。也就是说每一个属性类都有他们的权重，权重的参照标准是属性类一级的权重定义标准；属性类中的每一个属性也都有自己的权重，它们权重的参照标准是这一类的参照标准，即一个属性的权重大小是相对于其同类属性而言的。

为什么在评估过程中需要使用这种分级加权的评估模型呢？举例来说，从整体系统来看，就“安全性”属性类中的“最近6个月修复bug的数量”属性和“可靠性”属性类中的“平均失效间隔时间”属性，很难得出哪个属性更重要或量化地来看重要多少。

在同一属性类中不同子属性间的重要程度就比较好衡量，如，一般情况下“二次开发”属性类中的“是否提供可供开发的API接口”这一属性比同类中“是否支持第三方插件”这一属性对软件成熟度更为重要一些。

通过对各个属性类再赋予相应的权重又能比较准确地确定某一类属性整体上在体系中的重要程度。在类权重和属性权重的共同作用下，属性评分经过一定数学模式的计算将获得较为符合实际情况的软件成熟度量值。从而提高了评估结果的准确性、实用性。

在这里的评分设计中，我们给每一项具体的二级评测条目按照得到的具体的测试结果给出该软件在这一项条目中的成熟度评分，在设计时，我们简单地将软件的成熟度按照好坏给出了3个具体的档次，并分别给出了具体的评判标准和得分。值得注意的是，这里我们选取的是一部分简单的评估条件和测试样例。在实际的工作中往往需要更加多样性的条目和更多的档次来区分软件的成熟度。

2.2 评估条件和权重设计

在设计属性类权重和属性类中各个属性权重时，我们针对金融云的特殊环境，参考了OpenBRR、OMM、QSOS等现有标准，制定了最终权重标准。

参考表3中的11条具体的一级条目，限于篇幅的原因，这里将挑选其中比较有代表性的5个进行说明，可以用来展现评测模型在权重设计的部分的具体展开方式。将挑选开源许可证、安全性、功能性、效率性和可移植性5个方面来说明具体权重模型的建立和评分方法。

2.2.1 开源许可证

开源软件许可证相当于“使用合同”，对于这一个极为特殊的属性，我们将它的权重设置得比较高(20%)。对于金融云平台开发而言，一般情况下不愿意公开源代码，而如果使用了GPL许可的开源软件则会需要公开所有源代码及所做的修改。因此对于每种参与测评的开源软件，我们都应该在测评报告中指明其开源许可证。如果许可证不符合要求，那再优秀的其他属性都大打折扣。

对于开源许可证中的两个子属性“开源许可证类别”和“开源许可证冲突检测”来说，我们认为许可证类别比较重要，而存在的许可证冲突亦不可忽视。因此，我们将许可证类别设置为60%的权重，开源许可证冲突检测设置为40%的权重。

具体的评分策略见表4，开源许可证类别不明的记为1分，使用GPL、LGPL、OSI许可证的记3分，使用限制较低的符合用户需求的许可证记为0分。开源许可证冲突检测的评分按照是否存在软件公开性与商业保密性的冲突、专利许可授权的冲突、免费使用和盈利的冲突三方面着手。

表4 开源许可证属性类评分细则

2.2.2 安全性

考虑到金融云的实际环境，我们给安全性设置了比较高的权值(20%)。相较于openBRR和OMM模型，安全性的权值提高了很多。在安全性定义的7项子属性中，每项属性的重要性都差不多，因此子属性权值都设置在14%左右。

具体的评分标准见表5。其中有没有致力于安全性的信息按照有关安全性的文档数量打分，相关文档数量大于15记5分，大于5记3分，其他记1分。

表5 安全性属性类评分细则

2.2.3 功能性

功能性亦是对金融云十分重要的属性，我们给予它总分10%的权重占比。在功能性中我们定义了4项目子属性，分别占比30%、20%、20%和30%。具体如表6所示。

表6 功能性属性类评分细则

其中，需求功能完成程度，占功能性权重为30%，按照需求的完成程度打分。软件容错性，权重为20%，按照处理错误的能力记5分或1分。功能准确性，权重为20%，按照功能项目完成的准确程度打分。功能稳定性，按照功能项的稳定程度打分。

2.2.4 效率性

传统软件质量指标中，效率性占很大的权重，在金融云的标准中，效率性权重削弱。我们认为效率性和二次开发、可移植性、易用性等属性应处于同等地位，而低于安全性和功能性等属性。

对效率性的测评可以定量地转化成对时间特征和资源特征的测评。在设计测评指标时参考了传统软件测试的相关标准。对于输出结果更新周期，我们每次输出更新的间隔衡量，以毫秒为单位。处理时间以完成每次任务所需时间衡量，同样以毫秒为单位。吞吐率则使用每分钟处理的数据衡量。具体见表7。需要注意的是，对于不同类型的软件，其测评出的效率性可能差异极大，在具体测评时可以根据需要修正这一属性的测评值。

表7 效率性评分细则

2.2.5 可移植性

可移植性是传统软件质量特性中所考虑的因素，我们赋予它总分10%的权重。可移植性有四项子属性包括代码变更率、安装成功率、功能完整性。评分细则见表8。

表8 可移植性评分细则

其中，代码变更率是指即软件为移植而修改的代码数所占的比率，按照不同的百分比予以打分，比率越低得分越高。安装成功率即软件在目标环境下安装成功的概率，同样按照概率高低打分，得分与此概率成正比。功能完整性：即软件在目标环境中维持软件需求说明中规定功能性的要求，按照全部完成，部分完成和不能完成三级标准打分。

3 开源软件的整体模型设计

3.1 基于权重的可变多级加权平均模型

有了每一个子属性的属性评分的定义，我们就可以将收集到的数据通过一定的规律进行统计和计算得到最后的评分结果。

这里我们提出基于权重的可变多级加权平均模型将收集到的数据通过本模型进行计算可以得最终的评价结果。

对于13个项目一级属性，首先计算这13项属性的对应的值，假设每一项属性有子属性Pi，其中Pi的权重为Wi，而Pi在该项目上的得分为Si(其中i的取值从1到n，和二级子属性的具体个数有关)，那么我们可以得到该一级属性的具体得分为：

(1)

从上一小节中的表格中我们可以看到，每一项一级属性的最大得分为5分。

接下来要考虑的是，在得到13个具体的一级属性的得分之后如何去汇总计算。

一个普通的方法是：为所有的一级属性设置一个权重。

假设有n个一级属性，每一项一级属性的得分为Pi，每一项的权重为Wi那么可以得到最后的得分为：

(2)

考虑到不同用户的需求是不同的，那么不同用户对不同的一级属性所给予的关注也是不同的，变化的权重可以照顾到大多数用户的需求。

3.2 缺少部分数据时按照比例的评测模型

我们在第2节的权重模型中定义了13个大类之下50多个二级条目的评测内容，在理想的情况下可以按照上一小节中的模型来进行具体的成熟度评测工作。但是在测评中我们发现，有些测试数据是比较难以收集的，例如在实际的测评中我们发现，在评测社区活跃度之中的软件下载数量就比较难去进行界定。另外，在实际的工作中，也比较难去收集到所有的可以评测的条目的具体数据。

这里就需要我们考虑在缺少一部分评测数据条目的情况下如何去进行建模和评测工作。为了保持剩下的数据在评测时的权重比例的特征，这里我们提出一种方法，即在缺少一部分数据条目的情况下将现有的数据条目按照原来的比例去进行评测，按照有具体数据的条目的权重进行权重的重新分配，保证各个属性项的对比仍然是一致的。

接下来说明如何按照这种方法进行评测工作，我们列举如下的一个评测场景，见表9。

表9 缺少数据时的Kafka可靠性测试

在如上的测试可靠性的表格之中，该软件在3个有评测结果的条目中分别得到了8分、7分和9分，但是在其中的可用性一项上面缺少了对应的结果。此时如果按照之前的模型的话，由于缺少其中一项数据就无法给出一个合理的分数。

按照新的比例来评测的话，我们设定3个二级条目的比例为3∶2∶2,得分分别为8、7、9分，在这种情况下重新分配剩余的三项测评条目的权重，可以得到最终的评测结果为：

(8×3+7×2+9×2)/(3+2+2) ≈7.43

使用这一种方法，我们可以在缺少一部分对应的数据的时候仍然可以比较公正地给出该条目的测试结果。

3.3 基于数据规模的可信度参数

在实际的测试过程中，某些条目需要采集具体的数据来判定软件在这一个方面的成熟性，在测试软件稳定性的时候就需要运行软件来观察软件在多长的时间之内是可以稳定运行的。而这些数据的采集是具有一定的偶然性的，在多次的测试中也有可能得到偏差比较大的结果。

一个较好的解决方案是对该数据进行重复多次的数据采集，在数据的量足够大的情况下，该数据的可信程度较高。但是在实际的测试环境中，可能并不一定具有这样的条件，某些数据的采集可能是开销比较大的，在这样的情况下，重复进行多次的数据采集的成本是较高的。

同时，受限于测试环境，某些数据的采集是有一定的局限性的，即无法按照一定的规模来定向收集所有的测试数据。

当测试数据较少的时候，得到的结果和评分是具有一定的偶然性的。这种偶然性是比较难以消除的，但是我们可以在数据量较小的时候，能尽量减小偶然性对我们的测试结果带来的影响。

为此，我们引入一个可信度参数δ，而δ的最大值为1，在某一项测试数据的数据量较小的时候，δ的数值将相应减小，数据量越大，δ的值就将越大。在数据量达到我们需求的时候，δ的值将被设定为1。

考虑如表10所示的测试场景，我们仍然拿可靠性测试做具体的例子。

表10 加入可信度参数后的Kafka可靠性测试

根据表格中第四栏(数据量)，我们可以给出该测试条目的可置信度。我们可以看到，在测试通过率和稳定性上分别都只有1组的测试数据，因而在这样的情况下，我们给只有1组测试数据的两项条目的可置信程度δ=0.5，给有3组数据的条目的可置信制度δ=0.75，而对于有10组测试数据以上的条目的可置信程度δ=1。加入了可置信程度δ之后的加权平均模型，将可以尽量减小因为数据规模较小所带来的偶然性的影响，在测试中尽量做到客观而公正的评价。

4 基于模型的对比测试

在整体模型中，我们设计了11个大类的将近40多种不同的权重条目，同时在实际的评测工作中由于测评的展开方式会比较多，整体的测试开展工作是比较复杂的，这里我们会选取其中的若干个大类来进行具体的评测，而不是选取完整的评测条目和结果。

这里我们选取Kafka和RabbitMQ两款软件作为我们的测试对象。

考虑到依靠式(1)和式(2)计算权重是简单的，这里我们主要测试3.2和3.3节中的方法的有效性。

4.1 缺少部分条目的测试结果

Kafka在可靠性方面的得分如表11所示。

表11 无缺少数据时的Kafka可靠性测试

由表11，我们可以根据加权平均模型计算出Kafka在可靠性方面的得分为8.6分。

由表12，由于缺少可用性部分的内容，普通的方式无法计算最终的结果，根据3.2节中的方法可以将剩下的部分按照比例计算得分，由此可以计算出RabbitMQ在可靠性方面的得分为7.42分。可以比较出其中一款软件在可靠性方面要优于另外一款软件。在缺少一部分数据的情况下也可以进行计算。

表12 缺少数据时的RabbitMQ可靠性测试

4.2 数据量较小时的测试结果

重新来看上面一个小节中Kafka可靠性的测试结果，但是这次我们加入了可置信度的机制，在这样的情况下重新计算该款软件在可靠性上面的得分，如表13所示。得分为8.6分。

表13 Kafka的可靠性测试

加入可置信度机制之后结果如表14所示。

表14 Kafka的可靠性测试(加入可置信度机制之后)

经过重新计算后可以得到得分为8.2分。

可以看到，在加入可信度参数之后，软件的得分下降了，这是因为数据较小的情况下，可能有一定的偶然性，加入可置信度参数的评价之后可以在一定程度上弥补数据量较小带来的偶然性。

5 结 语

本文主要考虑了在有较为详细的金融开源软件评估体系的条目时。如何去收集数据并且根据一定的权重和建模系统来量化评估金融开源软件在各个方面的成熟度。

结合具体的实践例子说明了这样的权重体系在评价一款软件的质量时可以起到的作用，同时，使用可以变化权重的多级加权平均模型可以较好地规避数据产生比较大的偏离以及主观的风险。

这些模型提出了一个比较好的构想，为我们之后进一步金融开源软件成熟度评估体系提出了新的思路，为接下来的工作给出了一定的铺垫。