Page 90 - 《软件学报》2020年第10期

3066 Journal of Software 软件学报 Vol.31, No.10, October 2020

时,使用加权平均的方式,用户的专业水平与其评分的权值成正相关,通过这一途径,我们能够从大众对生态可
靠性的认知中,获取符合大多数人标准的可靠性评价,提升整个数据集的参考价值;
(4) 基于度量模型,软件自身的可靠性依赖于其供应链中软件的可靠性,因此,当其他途径更新了软件的可
靠性评分后,需要对该软件所属供应链上的软件进行更新,我们以评分发生更新的软件为起点,沿着供应关系逆
向遍历开源图谱并更新途经软件的可靠性评分,考虑到可靠性风险并不随供应路径的加长,而呈现衰减或增强
趋势,故我们以算数平均的方式计算新的可靠性评分,如公式(4)所示.这样不仅可以保证计算的简洁性,同时也
可以直观地表达其影响的传播,进一步地,还可以反映出多种风险叠加的后果.为了保证每一次更新过程能够收
敛,我们规定只有前 3 种更新途径会触发该更新过程.
3.3.2 处 理
如前文所述,供应链风险处理大致可以分为接受、避免、转嫁、
Table 2 Risk level of reliability 分担和缓解.考虑到开源软件供应链的特殊性,我们主要从可靠性风
表 2 可靠性风险等级 险的等级出发,针对接受、避免和缓解这 3 类提出风险处理方案.具
可靠性评分 风险
(3.5, 5] 低 体的风险等级划分见表 2,我们将风险等级划分为低、中、高 3 个等
(1.5, 3.5] 中 级.评分在 3.5 分以上的软件包风险较低,处理优先级较低,可以采用
[0, 1.5] 高
暂时接受的处理方式;评分在 1.5~3.5 分之间的软件包属于中等风险,

需要采用必要的措施缓解风险;评分不足 1.5 分的软件存在高可靠性风险,必须以最高优先级进行处理,做到完
全避免.
在本文提出的系统中,不会直接采取措施处理捕获到的可靠性风险,而是会为改善软件及其供应链的可靠
性提供决策支持.具体地,系统在展示软件可靠性度量信息的同时,会依据可靠性评分,由低到高推荐该软件的
供应链中需要被优化风险的软件包.配合第 2.3.1 节中的评分机制和第 2.3.3 节描述的监控机制,系统将根据优
化的结果重新评估软件的可靠性,最终使得被优化软件包所在供应链的可靠性风险降低.
3.3.3 监 控
供应链系统是一个动态系统,链上各个节点的状态会不断动态地发生变化,相比一般的产品,软件天然具有
快速迭代的特性,开源软件供应链的变化周期将进一步缩短,不确定因素更多.因此,可靠性风险管理的时效性
显得尤为重要,若不能及时捕获对可靠性风险有影响的事件,会导致系统对风险产生错误的评估.结合第 3.1 节
中描述的系统架构,我们基于多个组件配合实现可靠性风险监控流程,如图 5 所示(数据流程如图 5 中虚线部分
所示).整个流程分为 3 个阶段,在数据采集阶段,面向不同数据源(见表 3)实现相应的驱动程序,分别负责采集相
关数据,并以时序数据的形式保存;在数据分析阶段,分析器程序基于历史数据和最新捕获的数据进行事件提取
(在下文中详述);若发现有效事件,则会触发事件处理器分发至相应的处理流程,在目前的系统中,会触发可靠性
评估子流程,评估结果将反馈给监控时序数据,用于优化事件提取子流程的精确度.

Table 3 Risks to be monitored
表 3 风险监控
风险 数据源 相关度量模型属性 说明
贡献者地理分布 因政治因素引入的可靠性风险:如中美关系紧张,
新闻网站
政治风险 归属/性质 美政府要求 Google 公司限制华为手机安装并使
社交媒体
归属/国籍 用其提供的服务软件
专用网站
可替代性差 可替代性 不存在功能类似的软件或类似软件成熟度不足
用户补充
开源软件的主页、社交 通过更换开源协议来限制使用:如各大开源厂商
协议变动 开源协议类型
媒体及仓库 通过替换开源协议限制云厂商使用
社区活跃度/更新频率 超过 1 周无任何更新,若性质为个人项目,则风险
更新频率低 开源软件仓库
归属/性质 更大
社区活跃度/问题响应速度 反馈的问题超过 3 天无人响应,若性质为个人项
问题响应速度慢 开源软件社区
归属/性质 目,则风险更大
社区活跃度/贡献者数量 个人项目或贡献者数量少于 3 人,使得软件存在潜
贡献者数量低 开源软件仓库及社区
归属/性质 在的不可用风险