架构师之路:软件质量与模型解析

软件质量模型

架构师之路 — 软件架构 — 软件质量模型_数据

ISO/IEC 25010 标准定义的软件产品质量模型,包括以下 8 个大类:

  1. 功能适合性:功能完整度、功能正确性和功能恰当性;
  2. 性能效率:时间表现(e.g. 响应时间)、资源利用和容量;
  3. 兼容性:共存能力(e.g. 多版本组件共存)和互操作性;
  4. 可用性:可学习性、可运维性、用户错误保护(e.g. 自动纠错)、UI 美观度、可访问性;
  5. 可靠性:成熟度、可用性、容错性、可恢复性;
  6. 安全性:机密性、完整性、不可伪造性、权威性和可审计;
  7. 可维护性:模块度、可复用性、可分析性、可修改性、可测试性;
  8. 可移植性:可适配性、可安装性、可替代性。


性能

性能是指响应能力:响应特定事件所需的时间,或给定时间间隔内处理的事件数。性能具有以下指标:

  1. 延迟 :表示获得响应之前经过的时间间隔。
  2. 吞吐量:是指在固定时间间隔内获得的响应数。
  3. 可用容量:以上度量的结合体。
  4. 可调度的利用率:利用率是资源繁忙时间的百分比,而可调度的利用率是满足一定时间要求的最大利用率。
  5. 数据丢失:如果使用缓存来提高性能,那么缓存未命中将成为性能指标。


可靠性

可靠意味着质量或性能始终如一,且能够被信任。可靠性可以用平均故障间隔时间(MTBF)来表示,计算公式为:exp(-t/MTBF)。

可靠性很难用数字度量。但我们可以用代码复杂度、测试覆盖率来了解可靠性的边缘情况。遵循最佳工程实践将产生更好的产品。使用更好的管理实践和流程,可以实现更高的可靠性。


可用性

表示可用系统时间与总工作时间的比率。这是可靠性之上的另一层。它是系统掩盖或修复特定阈值(例如时间间隔)内故障的能力。公式:

架构师之路 — 软件架构 — 软件质量模型_架构师_02

  • MTBF = 平均无故障时间;
  • MTTR = 平均修复时间。


弹性

弹性指的是系统遇到问题时可以降级(而非中断服务),等待问题修复完成,表示的是系统在遇到严重故障时的持续运行能力。为实现弹性,需要提前设置防御机制(断路器模式)。弹性有时被称为容错性 。弹性系统指的是可以适应压力并持续运行的系统。很难用数字指标来度量弹性。


可信赖性

它包括可靠性、可用性、弹性、可持续性(可用性 / 弹性的比值)、可恢复性(弹性函数)和稳健性(可靠性函数)。我们应该始终将它们视为一个整体。

拿一辆汽车来说,如果它是新车并且是知名的可靠品牌(例如梅赛德斯),我们可以说它是可靠的。它有备用轮胎,所以有一些可用性。四轮驱动意味着弹性,其中两轮出故障还有两轮能工作(但性能会下降)。可持续性是可用性(备用轮胎)和弹性(四轮驱动)的综合。健壮性在这里可以指道路通过能力。如果汽车是电动的,那么充电速度就是一个可恢复性指标。


可伸缩性

它是系统在重负载下在可接受的阈值内的执行能力。它分为手动和自动可伸缩性两种,后者也叫灵活性 。当负载突增时,系统会做出反应并水平缩放(添加 / 删除更多实例)。我们可以查看 CPU 和内存来观察这些突发事件。这些突发操作完成后,系统将杀死不必要的实例,从而降低成本。垂直伸缩意味着我们向系统添加了更多物理资源(例如:更多的内存、更好的 CPU)。


安全性

它实际上是许多特点的集合:

  • 机密性:是指系统保护用户数据安全的能力;
  • 完整性:是保护外部资源免遭篡改的能力;
  • 身份验证:允许用户访问系统;
  • 授权:则告诉用户可以访问系统的哪些部分。通常使用 RBAC、ACL 或 ABAC 来实现。
  • 不可否认性:保证了消息的发送者不能否认自己发送了消息,并且接收者也不能否认自己接收了消息。


互操作性

它表示系统与外部系统通信的能力。合约接口是互操作性中最重要的概念,其涵盖了通信的所有方面,包括错误处理。


可调整性

也称为可变性,其描述了系统变化的难易程度,一般来说它是一个隐含的特征。

作为架构师,你要知道系统变化的概率是未知的,但一旦出现变化,系统应该能够优雅地应对。变化是软件世界中唯一确定的事物。话虽如此,我们不能将整个系统都设计为可变组件。如果每个组件都是即插即用组件,设计就做不完了。因此我们需要找到那些变化概率很高的部分。


改进可调整性的技术,有两个维度:

  1. 作为一名架构师,你需要确定哪些部分具有较高的变化概率;
  2. 作为软件工程师,你必须确保这些部分容易改动。


可部署性

由于 Docker 的诞生,现在我们可以在一台机器上拥有多个环境。可部署性是一种将代码转换为客户可用产品的机制。

CI/CD 系统中,每次代码推送都将触发一个生产部署。为此,应通过适应度函数和自动化测试来保护你的代码,它是抗脆弱性的关键部分。我们希望能按需部署,一键完成工作。我们也会部署硬件。使用基础架构即代码之类的技术可以提高效率。


可测试性

复杂的系统很难测试。以微服务架构为例,我们有很多独立开发的活动部件。这个特征经常会让步给其他特征,为了使系统可测试,我们需要能控制每个组件的输入和输出。

所以,我们尽量控制系统的复杂性,构建较小的组件,不要重新发明轮子,还应该编写可测试的代码,在适当的位置应用 TDD。


简单性

遵循 KISS 原则,但这条特征是很难实现的。一切都是权衡取舍,而大多数情况下这一条都会被牺牲掉。但如果我们需要在有限的时间内快速构建某些东西,那么就应该优先考虑简单性。

在构建 MVP(最小可行产品)时,我们关心的只有简单性。但要注意,实现目标之后,我们不应丢掉所有东西。不要与 PoC(概念验证)混淆。可重用性在这里也很重要。


可移植性

指的是系统从一个操作系统移植到另一个的能力,它会影响编程语言的选择。例如:Golang,它打包为二进制文件,不需要外部依赖项,因此是可移植的。有了容器技术之后,这个问题就很好解决了。


易用性

谈到易用性时通常会提到 “可配置性” ,即:用户自定义系统的能力。比如:通过 UI 主题更改外观和配置系统行为、控制用户访问权限等。

还有 “本地化”,也称为 i18n(internationalization)。它指的是系统支持多种标准的能力,一般是通过用户体验(UX)实现的。这里的标准指的是语言、货币、公制单位、字符编码等。本地化资源通常是静态的。

还有 “可访问性”,是另一个易用性特征。世界上有些人是残疾的(失明、听力受损、色盲),我们如何确保这些人可以受益于我们的系统呢?对于色盲来说,选择颜色会花很多时间。Siri/Alexa 是盲人的好帮手。考虑可访问性时,请想到我们的祖父母是不是能方便地使用我们的系统。

另外还有 “可支持性” ,比如说帮助页面或者 24x7 技术支持。我们应该努力让系统直观易用,这会影响可学习性,也就是用户习惯系统所需的时间。用户培训和帮助页面之类的策略很好用。


可扩展性

它是描述系统对即插即用组件需求程度的特征。对于使用内核架构的系统来说,这是很重要的特征。Eclipse Platform 和 OSGI 标准就是经典的例子。


抗脆弱性

它是系统应对压力、冲击、波动、噪声、错误、故障或攻击的能力。

改善抗脆弱性的前提,首先我们要敲打敲打系统。可以使用 CI/CD,它们本来就是做这种事的。每次代码更改都必须投入生产。


可升级性

它是指系统无缝升级自身的能力。首先我们需要为服务提供版本控制。下一步是使用蓝绿部署或金丝雀部署等策略进行零停机的时间部署。


合规性

不管我们需要的是哪种第三方工具和框架,都应该得到它们的合法授权。我们需要重视开源软件的合规性因素,因为它们可能会附带一些我们不想要的额外约束。

理想情况下,每家公司都应该有一个法律部门,但现实并非如此。适应度函数(例如许可证检查)可以保护我们免受列入黑名单的许可证的影响。在设计系统时,我们必须找到一种保护用户数据隐私的方法。


成本

可能是最重要的架构特点。一切都有成本,虚拟的、还是现实的都一样,任何成本都可以换算成金钱。开发团队要发工资,学习新技术或培训团队成员需要花钱。

  • 不尊重敏捷宣言是有代价的;
  • 错误的代码要付出代价;
  • 缺少单元测试会有代价;
  • 缺少 CI/CD 会有代价;
  • 没有基础架构即代码也会有代价;

这个列表是没有尽头的。

以 Scrum 流程为例,我个人认为它没什么用。在一个固定的周期(通常为两周)中,我们有这么多的仪式(计划、站会、演示、回顾),然后根据(猜出来的)估计值做计算,结果 Sprint 完成度 100%只是偶然而非必然。我们需要敏捷和适应,而不是盲目地遵循流程。我们应该减少会议和仪式,这样成本就会下降。我们应该专注于完成工作的本质要素。

然而,测试是必要的投资,快速前进的唯一方法就是正确前进。从长远来看,成本是会下降的,测试会减少错误的数量,从而减少成本。

代码质量是另一项投资。好的代码将带来更好的测试,提高稳健性、可维护性、可调整性等。与难以维护的系统相比,我们的更改花费的时间会更少,成本会下降。


可存档性

指系统保留历史数据记录的能力。在数据是一等公民的系统中(例如财务系统),这个特征非常重要。数据绝不会删除,而只会归档,这主要是考虑到法律要求。可归档性是对可审计性的支持。

首先是在数据上使用时间戳(例如 updatedOn、createdOn)。然后要有一个 Cron(周期)作业,将所有低于特定阈值的数据移入历史表中。另一种技术是将数据标记为软删除,但这会影响查询性能。


可审核性 / 可跟踪性

这是支持重构历史的系统特征。我们必须记录所有关键操作(尤其是在安全场景中),以便重现问题并从错误中学习经验。我们也可以将这些记录用作法律依据。

实现可审核性的关键是记录每个关键操作并集中存放这些记录。可以使用 ELK。


免责声明:本文系网络转载或改编,未找到原创作者,版权归原作者所有。如涉及版权,请联系删

QR Code
微信扫一扫,欢迎咨询~

联系我们
武汉格发信息技术有限公司
湖北省武汉市经开区科技园西路6号103孵化器
电话:155-2731-8020 座机:027-59821821
邮件:tanzw@gofarlic.com
Copyright © 2023 Gofarsoft Co.,Ltd. 保留所有权利
遇到许可问题?该如何解决!?
评估许可证实际采购量? 
不清楚软件许可证使用数据? 
收到软件厂商律师函!?  
想要少购买点许可证,节省费用? 
收到软件厂商侵权通告!?  
有正版license,但许可证不够用,需要新购? 
联系方式 155-2731-8020
预留信息,一起解决您的问题
* 姓名:
* 手机:

* 公司名称:

姓名不为空

手机不正确

公司不为空