一种开源组件评估方法、装置及计算机可读存储介质与流程

1.本发明涉及软件开发技术领域，尤其涉及一种开源组件评估方法、装置及计算机可读存储介质。


背景技术：

2.在现代软件开发中，开源组件的使用越来越多，据调查统计，绝大多数的软件开发都或多或少地使用了各类开源的软件组件，给软件开发带来了极大的便利，节省了很多开发人员的重复劳动。目前，开源的第三方组件往往都是研发团队在进行开发过程中，根据需要自行下载使用的，组件的使用往往过于随意，并没有统一的清晰明确的选择标准来辅助选取，存在较大的开源组件使用风险，如开源组件的运维和管理风险、漏洞和数据安全风险、合规和知识产权风险等。


技术实现要素：

3.本发明实施例的主要目的在于提供一种开源组件评估方法、装置及计算机可读存储介质，至少能够解决相关技术中研发人员在选取开源组件时缺乏系统性的选取标准，所导致的开源组件使用风险较大的问题。
4.为实现上述目的，本发明实施例第一方面提供了一种开源组件评估方法，该方法包括：
5.收集开源组件的基础数据，生成组件基础数据库；
6.基于所述组件基础数据库，分别计算所述开源组件不同评估属性下属的多个评估指标相应的二级评估数据；
7.基于所述二级评估数据，分别计算不同所述评估属性相应的一级评估数据；
8.根据所有所述一级评估数据，评估所述开源组件的成熟度。
9.为实现上述目的，本发明实施例第二方面提供了一种开源组件评估装置，该装置包括：
10.生成模块，用于收集开源组件的基础数据，生成组件基础数据库；
11.第一计算模块，用于基于所述组件基础数据库，分别计算所述开源组件不同评估属性下属的多个评估指标相应的二级评估数据；
12.第二计算模块，用于基于所述二级评估数据，分别计算不同所述评估属性相应的一级评估数据；
13.评估模块，用于根据所有所述一级评估数据，评估所述开源组件的成熟度。
14.为实现上述目的，本发明实施例第三方面提供了一种电子装置，该电子装置包括：处理器、存储器和通信总线；
15.所述通信总线用于实现所述处理器和存储器之间的连接通信；
16.所述处理器用于执行所述存储器中存储的一个或者多个程序，以实现上述任意一种开源组件评估方法的步骤。
17.为实现上述目的，本发明实施例第四方面提供了一种计算机可读存储介质，该计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现上述任意一种开源组件评估方法的步骤。
18.根据本发明实施例提供的开源组件评估方法、装置及计算机可读存储介质，收集开源组件的基础数据，生成组件基础数据库；基于组件基础数据库，分别计算开源组件不同评估属性下属的多个评估指标相应的二级评估数据；基于二级评估数据，分别计算不同评估属性相应的一级评估数据；根据所有一级评估数据，评估开源组件的成熟度。通过本发明的实施，采用不同的层级由下至上对开源组件进行评估，评估模型结构清晰，易于执行，且每一层级均从多维度纳入多个评估因素，评估模型的系统性强，由此可准确地、全面地对开源组件的可用性进行评估，有效降低了开源组件的使用风险。
19.本发明其他特征和相应的效果在说明书的后面部分进行阐述说明，且应当理解，至少部分效果从本发明说明书中的记载变的显而易见。
附图说明
20.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
21.图1为本发明第一实施例提供的开源组件评估方法的流程示意图；
22.图2为本发明第一实施例提供的一种开源组件评估模型的结构示意图；
23.图3为本发明第一实施例提供的属性权重分配方法的流程示意图；
24.图4为本发明第一实施例提供的成熟度计算方法的流程示意图；
25.图5为本发明第二实施例提供的开源组件评估装置的程序模块示意图；
26.图6为本发明第三实施例提供的电子装置的结构示意图。
具体实施方式
27.为使得本发明的发明目的、特征、优点能够更加的明显和易懂，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而非全部实施例。基于本发明中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
28.第一实施例：
29.开源组件分析通常分为代码质量、软件成分和知识产权分析几个方面，代码质量关注功能的完善程度、成分分析关注开源代码所使用的其他开源组件及其相关的安全情况，知识产权分析关注被检测对象与其他已开源组件在代码层面的相似度、或者说一致性来判断是否有侵权。目前业界对开源代码的评估和研究各有侧重点，比如对组件成分分析工具普遍存在组件分析不准确和数据误差大的情况，而单个商业工具大多关注软件成分分析或者源代码层面的检测而不关注代码质量，很难对开源代码提供全方位的分析。
30.为了解决相关技术中研发人员在选取开源组件时缺乏系统性的选取标准，所导致的开源组件使用风险较大的问题，本实施例提出了一种开源组件评估方法，如图1所示为本
实施例提供的开源组件评估方法的流程示意图，本实施例提出的开源组件评估方法包括以下的步骤：
31.步骤101、收集开源组件的基础数据，生成组件基础数据库。
32.具体的，本实施例的开源组件可以来源于github和openhub等开源社区，针对本实施例收集开源组件的基础数据的具体实现，在优选的实施方式中，可以在一方面集成灰盒工具收集开源组件自身代码的安全漏洞数据，另一方面集成白盒工具收集开源组件自身代码的安全质量数据、代码指纹数据，又一方面集成软件组合分析工具收集开源组件的开源许可数据、组件成分数据。当然，在实际应用中，除以上几个主要数据收集方面之外，还可以根据实际需要扩展集成更多的数据收集工具来实现更多类型的数据的收集，以扩充数据源。
33.步骤102、基于组件基础数据库，分别计算开源组件不同评估属性下属的多个评估指标相应的二级评估数据。
34.如图2所示为本实施例提供的一种开源组件评估模型的结构示意图，针对每个待评估的开源组件，本实施例对其评估问题进行多目标规划，其中，评估属性为一级评估对象，评估指标为评估属性下属的二级评估对象。在本实施例中，一级层次将其划分为属性评估，该层次下具有多个不同的评估属性，如图2中的评估属性1至评估属性n，评估属性可以包括：建设和管理属性、活跃度属性、软件支持属性、知识产权属性、代码质量属性、安全属性、其它属性；二级层次则是在各一级层次基础上继续划分的指标评估，针对各评估属性分别划分出不同的评估指标，如图2中的评估指标1至评估指标n，具体的评估指标类型在后续实施方式中进行具体阐述。
35.步骤103、基于二级评估数据，分别计算不同评估属性相应的一级评估数据。
36.具体的，本实施例采用自下而上的评估方式进行开源组件评估，也即先对层级处于二级的评估指标进行评估，然后在结合各评估指标的评估数据向上评估其所归属的评估属性。
37.步骤104、根据所有一级评估数据，评估开源组件的成熟度。
38.具体的，在本实施例中成熟度与开源组件的适用性正相关，也即成熟度越高，开源组件的使用安全性以及与技术选型的匹配度越高。本实施例采用不同的层级由下至上对开源组件进行评估，评估模型结构清晰，易于执行，且每一层级均从多维度纳入多个评估因素，评估模型的系统性强，由此可准确地、全面地对开源组件的可用性进行评估，有效降低了开源组件的使用风险。
39.在本实施例一种可选的实施方式中，上述评估开源组件的成熟度的步骤之后，还包括：计算开源组件的成熟度与预设成熟度阈值之间的差值；将差值与预设差值阈值进行比较。
40.其中，在差值小于差值阈值时，继续集成备用数据收集工具，然后返回收集开源组件的基础数据，生成组件基础数据库的步骤。
41.具体的，本实施例的成熟度阈值用于评估开源组件是否符合使用需求，而在实际应用中，当成熟度计算结果与成熟度阈值较为接近时，出于偶然误差的影响，该成熟度计算结果并不能有效采信，由此，本实施例进一步扩展其它数据收集工具扩展组件基础数据库，提高数据库中的数据量，并重新根据扩展后的数据再次进行二级评估数据以及一级评估数
据的计算，并重新输出开源组件的成熟度评估结果，并将重新输出的成熟度进行采信(也即确认有效)，以提高开源组件评估的准确性。
42.在本实施例一种可选的实施方式中，上述分别计算开源组件不同评估属性下属的多个评估指标相应的二级评估数据的步骤，具体包括：分别将开源组件各评估属性的属性权重以及评估属性的总数量输入至第一计算公式，计算各评估属性的总分值；分别将各评估属性下属的评估指标的总数量、各评估指标的指标权重以及评估属性的总分值输入至第二计算公式，计算各评估指标相应的二级评估数据。
43.其中，第一计算公式表示为p＝(100/n1)*w1，p表示不同评估属性的总分值，n1表示评估属性的总数量，w1表示属性权重，第二计算公式表示为q＝(p/n2)*w2，q表示二级评估数据，n2表示各评估属性下属的评估指标的总数量，w2表示指标权重。
44.相对应的，基于二级评估数据，分别计算不同评估属性相应的一级评估数据的步骤，包括：分别将不同评估属性下属的所有二级评估数据进行求和，得到相应的一级评估数据。
45.以开源组件的建设和管理属性为例，开源项目建设和管理评估点是关于开源组件的项目在代码托管平台或社区中的管理情况的评估考虑点，主要的下级评估指标有：主要开发者人相关信息(对开发者信息的评估，可以参考其已有项目的贡献，业界口碑等信息，来评估开源组件可用性)、主要开发人员数量(人数是否大于3)、其他开发者人相关信息(是否有著名开源社区贡献者)、其他开发人员数量(人数是否大于3)、开发目的是否用于社区、开源组件是否有代码托管平台信息、开源组件是否有官方网站信息、开源组件是否有计划表、里程碑等信息、是否有组织开源社区活动(如培训，研讨会等)等，以上9个二级指标在计算成熟度分数(评估总分100分)的时候，首先用以下公式求出建设和管理属性的总分：
46.建设和管理属性的总分＝(100/评估属性的总数量)*建设和管理属性的权重；
47.然后再通过以下公式求出建设和管理属性的二级评估指标的分数：
48.建设和管理属性二级指标分数＝(建设和管理属性的总分/二级指标的总数量)*二级指标的权重；
49.最后，再计算所有二级指标项的总和，即得到建设和管理属性的分数，计算公式如下：
50.建设和管理属性评估值＝二级指标1的分数+二级指标2的分数+
…
+二级指标n的分数。
51.以开源组件的活跃度属性为例，开源项目的活跃度评估的目的是对开源项目进行分析，了解最新开源技术，剖析国内外开源现状。评估点主要考虑以下几点下级评估指标：发行历史(每个月是否有版本发布)、最新版本发布时间(三个月内是否有更新)、最新稳定版发布时间(一年内是否有稳定版本)、主要版本时间间隔(每三个月是否有主版本发布)、下载次数(是否超过1000次)、收藏次数star(是否超过1000次)、关注次数watch(是否超过1000次)、克隆次数fork(是否超过1000次)、被引用次数(作为三方组件被引用)(是否超过1000次)、组件的讨论次数issues(是否超过1000次)等，以上10个二级指标在计算分数(评估总分100分)的时候，首先用以下公式求出活跃度属性的总分：
52.活跃度属性的总分＝(100/评估属性的总数量)*活跃度属性的权重；
53.然后再通过以下公式求出活跃度属性的二级评估指标的分数：
54.活跃度属性二级指标分数＝(活跃度属性的总分/二级指标的总数量)*二级指标的权重；
55.最后，再计算所有二级指标项的总和，即得到活跃度属性的分数，计算公式如下：
56.活跃度属性评估值＝二级指标1的分数+二级指标2的分数+
…
+二级指标n的分数。
57.以开源组件的软件支持属性为例，开源组件的软件支持评估可以了解到该开源组件是否有商业机构负责提供商业支撑及客户服务，了解到是否有充足的资源信息可共享，通过对这些信息的评估，可以了解到该开源组件的可获得的支撑度，软件支持评估点主要考虑以下几点：是否是著名基金会管理、是否是著名it公司关注和管理、是否有技术支持维护服务、是否有教育培训服务、是否支持云服务、是否有安装部署和使用手册、发行的书籍数量。以上7个二级指标在计算分数(评估总分100分)的时候，首先用以下公式求出软件支持属性的总分：
58.软件支持属性的总分＝(100/评估属性的数量)*软件支持属性的权重；
59.然后再通过以下公式求出软件支持属性的二级评估指标的分数：
60.软件支持属性二级指标分数＝(软件支持属性的总分/二级指标的总数量)*二级指标的权重；
61.最后，再计算所有二级指标项的总和，即得到软件支持属性的分数，计算公式如下：
62.软件支持属性评估值＝二级指标1的分数+二级指标2的分数+
…
+二级指标n的分数。
63.以开源组件的知识产权属性为例，开源组件知识产权的成熟度主要评估开源许可协议兼容性，当把不同开源许可协议的代码组合成一个大程序发布时，各个许可协议条款之间的冲突造成被许可人利益受损该如何解决等，这就是许可协议兼容性的问题。其中，强传染性许可协议之间的兼容性：一般情况下强传染性许可协议之间很难兼容；强传染性与弱传染性许可协议之间的兼容性：这两种许可协议之间的规定都是相互矛盾的，比如gpl许可协议要求“用户必须以该许可协议的许可条款发布整个程序的源代码”，而mpl
‑
1.1则要求修改作品“受本许可协议的条款管辖”；强传染性许可协议和无传染性许可协议之间的兼容性：绝大多数情况下是兼容的，但也有另外，如gpl
‑
2.0许可协议第六条规定“您不可以就本许可协议赋予接收人的权利附加任何进一步的限制”，而apache
‑
2.0许可协议中有专利报复条款，两个条款明显冲突造成两个许可协议不能兼容；弱传染性许可协议之间的兼容性：此类兼容性问题较为模糊，业内共识一般情况下是兼容的；无传染性许可协议之间的兼容性：业内共识一般情况下是兼容的。知识产权属性的下级评估点主要考虑以下几点指标：当前组件的许可协议是否是弱传染性、使用的第三方组件是否含无强传染性的组件、使用的第三方组件是否许可兼容、当前组件是否违反许可协议里的条款，以上4个二级指标在计算分数(评估总分100分)的时候，首先用以下公式求出活跃度属性的总分：
64.知识产权属性的总分＝(100/评估属性的数量)*知识产权属性的权重；
65.然后再通过以下公式求出知识产权属性的二级评估指标的分数：
66.知识产权属性二级指标分数＝(知识产权属性的总分/二级指标的总数量)*二级指标的权重；
67.最后，再计算所有二级指标项的总和，即得到知识产权属性的分数，计算公式如
下：
68.知识产权属性评估值＝二级指标1的分数+二级指标2的分数+
…
+二级指标n的分数。
69.在本实施例一种可选的实施方式中，上述分别计算开源组件不同评估属性下属的多个评估指标相应的二级评估数据的步骤，具体包括：针对开源组件各评估属性，将评估属性下属的各评估指标的基础分值以及指标得分比值输入至第三计算公式，计算各评估指标相应的二级评估数据；其中，第三计算公式表示为q＝x*y，q表示二级评估数据，x表示基础分值，y表示指标得分比值。
70.相对应的，上述基于二级评估数据，分别计算不同评估属性相应的一级评估数据的步骤，具体包括：分别将不同评估属性下属的所有二级评估数据与对应指标权重的乘积进行求和，得到相应的一级评估数据。
71.以开源组件的代码质量属性为例，开源组件的成熟度很重要的一个因素是开源组件的代码质量，好的代码质量一定是功能完善、整洁的，能够帮助阅读的人快速理解和定位。好的代码可以加快应用的开发迭代速度，不必花过多的时间来修复bug和完善代码。本实施例可以从开源代码的错误率，测试覆盖率和代码复杂度三个纬度来综合考虑，其中各项的权重为【错误率：50％，测试覆盖率：20％，代码复杂度：30％】，代码质量属性部分的总体得分可按如下计算公式获得：总分＝错误率得分*50％+测试覆盖率*20％+代码复杂度*30％；具体各项得分计算方式如下：
72.错误率：开源代码中存在的问题数量多少直接决定了其功能的完善程度，业界引用千行代码中平均含有的bug数量来衡量，本实施例在获取到开源代码所有问题数量和代码行数后，即可算出该值。其计算公式为：千行代码bug率＝bug数量/(代码行数/1000)，度量的标准是千行代码bug率数值越小质量越好。cmmi级别中和bug率相关的信息本实施例的评分标准如下：
[0073][0074][0075]
综上所述，错误率得分计算公式为：
[0076]
错误率得分＝错误率基础分值*错误率得分比值。
[0077]
代码覆盖率：对于一个软件，用户学习、操作、准备输入和理解输出所作努力的程度，如开源代码可读性高、容易使用，代码覆盖率表示在单元测试运行期间，代码中有多少行代码或可执行分支被测试。覆盖率越低，所执行的单元测试的质量就越低。代码覆盖率是“功能适用性”和“可靠性”的一个度量指标。
[0078][0079][0080]
在开源代码单元测试执行成功且覆盖率高的情况下，任务开源代码的整体完善程度比较高，代码质量检测工具sonar会综合以上数据计算出总的代码覆盖率的百分比，所以本项得分的计算公式为：代码覆盖率得分＝代码覆盖率基础分*代码覆盖率百分比。
[0081]
复杂度：圈复杂度是一种代码复杂度的衡量标准。它是一种固定的数据模型计算方式。它可以用来衡量一个模块判定结构的复杂程序，数量上表现为独立线性路径条数，也可理解为覆盖所有的可能情况最少使用的测试用例数。圈复杂度高说明程序代码的判断逻辑复杂，可能质量低且难以测试和维护。
[0082]
1.&&、||条件判断符号+1
[0083]
2.if，else if，else，switch分支语句+1
[0084]
3.for、while、do while循环语句+1
[0085]
4.catch捕获异常语句+1
[0086]
5.break、continue终端语句+1
[0087]
6.如果if、for、while、do while、catch存在嵌套时，里层的语句相对于外层+1
[0088]
sonar要求认知复杂度不能高于15，所以我们以复杂度计算结果和方法总数的比例来衡量开源代码整体的复杂度，整体复杂度＝圈复杂度大于15的数量/总方法数，如果整体复杂度大于50％得0分，小于30％得满分。
[0089]
继续以开源组件的安全属性为例，开源组件安全属性评估从开源代码本身，开源代码依赖的其他组件和公开的漏洞三个方面来衡量其对安全处理的完善性，其中各项的权重为【源代码安全：40％，依赖安全：20％，公开漏洞：40】，安全属性部分总体得分的可按如下计算公式获得：总分＝源代码安全得分*40％+依赖安全*20％+公开漏洞*40％；具体各项得分计算方式如下：
[0090]
源代码安全：对开源代码本身的安全检测，主要以sast、iast和dast类工具为主，本方案中我们将综合三种工具对开源代码作全方位的检测，对各工具检测的结果经过去重、分析后得到综合的源代码安全报告，并从以下几个方面来计算源代码安全的分值：
[0091][0092]
源代码的安全漏洞得分主要以漏洞的安全等级为主，漏洞总数可自行决定是否参与分值计算，计算公式为：源代码安全得分＝源代码安全基础分值*安全漏洞严重性比率。
[0093]
依赖安全：依赖安全是在开源代码引用其他开源组件或者代码时，对该开源代码进行组件成分分析，从而获取间接引入组件的公开漏洞情况来判断依赖的安全情况。本项目中引入的软件组合分析工具从所依赖组件的公开漏洞分数和数量上对依赖组件做综合分析并给出a～e的五个等级评价，每个级别分数对应比值为：a、依赖安全得分比值100％，b、依赖安全得分比值80％，c、依赖安全得分比值60％，d、依赖安全得分比值40％，e、依赖安全得分比值20％。综上所述，依赖安全得分计算公式为：依赖安全得分＝依赖安全基础分值*依赖安全得分比值。
[0094]
公开漏洞：公开漏洞是业界公开的该开源代码中所含有的已披露的安全漏洞，其形成原理和攻击重现方法已被公开，危害性极强。本实施例中引入的软件组合分析工具可以通过对开源代码分析后生成该组件的安全报告，报告给出了从a～e的五个等级评价，每个级别分数对应比值为：a、依赖安全得分比值100％，b、依赖安全得分比值80％，c、依赖安
全得分比值60％，d、依赖安全得分比值40％，e、依赖安全得分比值20％。综上所述，公开漏洞得分计算公式为：公开漏洞得分＝公开漏洞基础分值*公开漏洞得分比值。
[0095]
最后以开源组件的其它属性为例，其它属性部分，本实施例主要衡量开源代码的可移植性、可靠性和可维护性，其中各项的权重为【可移植性：20％，可靠性：40％，可维护性：40％】，其它属性部分总体得分的可按如下计算公式获得：总分＝可移植性得分*20％+可靠性*40％+可维护性*40％；具体各项得分计算方式如下：
[0096]
可移植性：软件从一个计算机系统或环境移植到另一个系统或环境的容易程度，或者是一个系统和外部条件共同工作的容易程度。它涉及适应性和易替换性。计算方法为支持的系统数量，比如windows，centos，macos，每支持一种平台可移植性得分比值增加20％，可移植性得分比值总比值不超过100％。对于跨平台类开源代码和平台无关，可获得满分比值100％，比如java、python等。综上所述，可移植性得分计算公式为：可移植性得分＝可移植性基础分值*可移植性得分比值。
[0097]
可靠性：在规定的时间和条件下，软件所能维持其正常的功能操作、性能水平的程度/概率，如成熟性越高可靠性就越高，本实施例可以从如下几个方面来衡量：
[0098][0099]
代码质量度量工具sonar根据以上数据项计算得到可靠性的整体得分并给予a～e五个等级，每个级别分数对应比值为：a、可靠性得分比值100％，b可靠性得分比值80％，c、
可靠性得分比值60％，d、可靠性得分比值40％，e、可靠性得分比值20％。综上所述，可靠性得分计算公式为：可靠性得分＝可靠性基础分值*可靠性得分比值。
[0100]
可维护性：当一个软件投入运行应用后，需求发生变化、环境改变或软件发生错误时，进行相应修改所做努力的程度。它涉及模块化、复用性、易分析性、易修改性、易测试性等。
[0101][0102][0103]
代码质量度量工具sonar根据以上数据项计算得到可维护性的整体得分并给予a～e五个等级，每个级别分数对应比值为：a、可维护性得分比值100％，b、可维护性得分比值80％，c、可维护性得分比值60％，d、可维护性得分比值40％，e、可维护性得分比值20％。综上所述，可维护性得分计算公式为：可维护性得分＝可维护性基础分值*可维护性得分比
值。
[0104]
如图3所示为本实施例提供的一种属性权重分配方法的流程示意图，在本实施例一种可选的实施方式中，上述分别将开源组件各评估属性的属性权重以及评估属性的总数量输入至第一计算公式的步骤之前，还具体包括如下流程：
[0105]
步骤301、获取开源组件所需应用的开发项目的项目属性；
[0106]
步骤302、基于项目属性确定开源组件各评估属性对应的重要性等级；
[0107]
步骤303、基于重要性等级为各评估属性对应分配属性权重。
[0108]
具体的，本实施例可以将开源组件评估问题视为一个多目标规划问题，多目标规划问题归结为求解相应评价函数的最优化解。在实际应用中，采用不同形式的评价函数可求得多目标规划问题的不同意义下的结果。在本实施例中，根据开源组件涉及的开发项目类型的不同，所侧重的评估属性有所不同，本实施例根据具体的评估项重要性进行不同的权值分配，从而得到更优的评估结果。
[0109]
如图4所示为本实施例提供的一种成熟度计算方法的流程示意图，在本实施例一种可选的实施方式中，上述根据所有一级评估数据，评估开源组件的成熟度的步骤，具体包括如下流程：
[0110]
步骤401、基于各一级评估数据以及对应标准数据，获取数据达标程度；
[0111]
步骤402、基于数据达标程度确定各评估属性的属性评估得分；
[0112]
步骤403、将所有属性评估得分进行加权平均计算，得到开源组件的成熟度。
[0113]
具体的，在本实施例中，可以对每一项评价指标确定一个满意值和不允许值，以满意值为上限，以不允许值为下限，计算各指标实现满意值的程度，并以此确定各指标的分数，再经过加权平均进行综合，从而评价被评估对象的综合状况。由此，减少了因单一标准评价而造成的评价结果偏差，设置了在相同条件下评价某指标所参照的评价指标值范围，并根据指标实际值在标准范围内所处位置计算评价得分。
[0114]
根据本发明实施例提供的开源组件评估方法，收集开源组件的基础数据，生成组件基础数据库；基于组件基础数据库，分别计算开源组件不同评估属性下属的多个评估指标相应的二级评估数据；基于二级评估数据，分别计算不同评估属性相应的一级评估数据；根据所有一级评估数据，评估开源组件的成熟度。通过本发明的实施，采用不同的层级由下至上对开源组件进行评估，评估模型结构清晰，易于执行，且每一层级均从多维度纳入多个评估因素，评估模型的系统性强，由此可准确地、全面地对开源组件的可用性进行评估，有效降低了开源组件的使用风险。
[0115]
第二实施例：
[0116]
为了解决相关技术中研发人员在选取开源组件时缺乏系统性的选取标准，所导致的开源组件使用风险较大的问题，本实施例示出了一种开源组件评估装置，具体请参见图5，本实施例的开源组件评估装置包括：
[0117]
生成模块501，用于收集开源组件的基础数据，生成组件基础数据库；
[0118]
第一计算模块502，用于基于组件基础数据库，分别计算开源组件不同评估属性下属的多个评估指标相应的二级评估数据；
[0119]
第二计算模块503，用于基于二级评估数据，分别计算不同评估属性相应的一级评估数据；
[0120]
评估模块504，用于根据所有一级评估数据，评估开源组件的成熟度。
[0121]
在本实施例的一些实施方式中，第一计算模块具体用于：分别将开源组件各评估属性的属性权重以及评估属性的总数量输入至第一计算公式，计算各评估属性的总分值；分别将各评估属性下属的评估指标的总数量、各评估指标的指标权重以及评估属性的总分值输入至第二计算公式，计算各评估指标相应的二级评估数据；其中，第一计算公式表示为p＝(100/n1)*w1，p表示不同评估属性的总分值，n1表示评估属性的总数量，w1表示属性权重，第二计算公式表示为q＝(p/n2)*w2，q表示二级评估数据，n2表示各评估属性下属的评估指标的总数量，w2表示指标权重。相应的，第二计算模块具体用于：分别将不同评估属性下属的所有二级评估数据进行求和，得到相应的一级评估数据。
[0122]
进一步地，在本实施例的一些实施方式中，开源组件评估装置还包括：分配模块，用于获取开源组件所需应用的开发项目的项目属性；基于项目属性确定开源组件各评估属性对应的重要性等级；基于重要性等级为各评估属性对应分配属性权重。
[0123]
在本实施例的另一些实施方式中，第一计算模块具体用于：针对开源组件各评估属性，将评估属性下属的各评估指标的基础分值以及指标得分比值输入至第三计算公式，计算各评估指标相应的二级评估数据；其中，第三计算公式表示为q＝x*y，q表示二级评估数据，x表示基础分值，y表示指标得分比值。相应的，第二计算模块具体用于：分别将不同评估属性下属的所有二级评估数据与对应指标权重的乘积进行求和，得到相应的一级评估数据。
[0124]
在本实施例的一些实施方式中，生成模块在执行收集开源组件的基础数据的功能时，具体用于：集成灰盒工具收集开源组件自身代码的安全漏洞数据，集成白盒工具收集开源组件自身代码的安全质量数据、代码指纹数据，集成软件组合分析工具收集开源组件的开源许可数据、组件成分数据。
[0125]
进一步地，在本实施例的一些实施方式中，开源组件评估装置还包括：比较模块，用于计算开源组件的成熟度与预设成熟度阈值之间的差值；将差值与预设差值阈值进行比较。相应的，生成模块还用于：在差值小于差值阈值时，继续集成备用数据收集工具，并收集开源组件的基础数据，生成组件基础数据库。
[0126]
在本实施例的一些实施方式中，评估模块具体用于：基于各一级评估数据以及对应标准数据，获取数据达标程度；基于数据达标程度确定各评估属性的属性评估得分；将所有属性评估得分进行加权平均计算，得到开源组件的成熟度。
[0127]
应当说明的是，前述实施例中的开源组件评估方法均可基于本实施例提供的开源组件评估装置实现，所属领域的普通技术人员可以清楚的了解到，为描述的方便和简洁，本实施例中所描述的开源组件评估装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
[0128]
采用本实施例提供的开源组件评估装置，收集开源组件的基础数据，生成组件基础数据库；基于组件基础数据库，分别计算开源组件不同评估属性下属的多个评估指标相应的二级评估数据；基于二级评估数据，分别计算不同评估属性相应的一级评估数据；根据所有一级评估数据，评估开源组件的成熟度。通过本发明的实施，采用不同的层级由下至上对开源组件进行评估，评估模型结构清晰，易于执行，且每一层级均从多维度纳入多个评估因素，评估模型的系统性强，由此可准确地、全面地对开源组件的可用性进行评估，有效降
低了开源组件的使用风险。
[0129]
第三实施例：
[0130]
本实施例提供了一种电子装置，参见图6所示，其包括处理器601、存储器602及通信总线603，其中：通信总线603用于实现处理器601和存储器602之间的连接通信；处理器601用于执行存储器602中存储的一个或者多个计算机程序，以实现上述实施例一中的开源组件评估方法中的至少一个步骤。
[0131]
本实施例还提供了一种计算机可读存储介质，该计算机可读存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、计算机程序模块或其他数据)的任何方法或技术中实施的易失性或非易失性、可移除或不可移除的介质。计算机可读存储介质包括但不限于ram(random access memory，随机存取存储器),rom(read
‑
only memory，只读存储器),eeprom(electrically erasable programmable read only memory，带电可擦可编程只读存储器)、闪存或其他存储器技术、cd
‑
rom(compact disc read
‑
only memory，光盘只读存储器)，数字多功能盘(dvd)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。
[0132]
本实施例中的计算机可读存储介质可用于存储一个或者多个计算机程序，其存储的一个或者多个计算机程序可被处理器执行，以实现上述实施例一中的方法的至少一个步骤。
[0133]
本实施例还提供了一种计算机程序，该计算机程序可以分布在计算机可读介质上，由可计算装置来执行，以实现上述实施例一中的方法的至少一个步骤；并且在某些情况下，可以采用不同于上述实施例所描述的顺序执行所示出或描述的至少一个步骤。
[0134]
本实施例还提供了一种计算机程序产品，包括计算机可读装置，该计算机可读装置上存储有如上所示的计算机程序。本实施例中该计算机可读装置可包括如上所示的计算机可读存储介质。
[0135]
可见，本领域的技术人员应该明白，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件(可以用计算装置可执行的计算机程序代码来实现)、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。
[0136]
此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、计算机程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。所以，本发明不限制于任何特定的硬件和软件结合。
[0137]
以上内容是结合具体的实施方式对本发明实施例所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。