软件架构师质量要求终极指南：满足利益相关者的期望

发现现代技术和工具，以有效地引出、记录和改进软件计划的质量要求的管理。

每个利益相关者都有它们：非功能性需求或至少对下一个软件计划的（非功能性）期望。

• “它必须要快。”

• “它应该很容易维护。”

• “它应该是可扩展的。”

• “它应该提供良好的用户体验”

• “可以快速轻松地开发新功能。”

但往往没有人能够解释性能效率、可扩展性、可用性、耦合性、可维护性等含义。

软件架构师的一项基本任务是确保特定软件系统的质量目标变得具体并且可衡量。

因此，让我们从现实世界中一个经验丰富（“有趣”）的故事开始，作为对一个看似无聊的高质量主题的介绍。👇

用一个有趣的故事来介绍一个看似无聊的话题

我经常作为各个中小企业的 CTO 的顾问奔波在路上。几年前，我支持一家中小企业推出新软件产品。

他自豪地向我展示了这个特定软件系统的“非功能需求”列表，并说

“看，我们已经确定了新系统需要满足的未来非功能性要求。” 他向我展示了大约 30 个质量特征的列表。

该列表看起来像这样：

• 可扩展

• 可靠的

• 可用

• 安全的

• 可维护

• 便携的

• 高效的

• 兼容的

• 无障碍

• 可测试

• 灵活的

• 可互操作

• 性能出色

• 有弹性的

• 模块化的

• 直觉的

• 可定制

• 反应灵敏

• 持续的

• 容错

• 可重复使用的

• 可持续的

• 强壮的

• 可升级

• 可本地化

• 简洁的

• 大容量

• 可追溯

这份清单或这些“质量特征”当然是完全没有用的。

因为

1. 整个开发团队甚至无法从这个巨大的列表中说出五个质量属性。

2. 例如，在不切实际的情况下，有人查阅包含这 30 个质量属性的 Confluence 页面，他们不会知道“弹性”或这些其他质量属性的含义。

我知道这个非功能性主题可能很无聊或烦人，因为乍一看它不包含任何技术内容。

但作为一名优秀的软件架构师——当然还有一名优秀的需求工程师/产品负责人——你必须完成这项工作，并使它们具体化并确定优先级。

为什么？

因为这些——尤其是这些——是您的驱动因素，更重要的是，是您几乎所有软件架构决策的原因。

但好消息是，除了所有这些无聊的质量内容之外，还有良好的现代技术来开发和维护明确的非功能性需求。

ISO 标准简介及其实际应用

😀 请不要仅仅因为您已经阅读了“ISO 标准”就停止阅读此处。让我们从可能很无聊的东西开始，即官方 ISO/IEC 25010 标准。

该质量模型是评估系统质量的系统的基石。质量模型定义了在评估软件产品的属性时应考虑哪些质量特征。

ISO/IEC 25010:2023 定义的产品质量模型包含如下图所示的八个质量特性：

以下是 ISO/IEC 25010:2023 质量特征的简要总结：

• 功能适用性：衡量软件满足明示和暗示需求的能力。

1. 功能完整性

2. 功能正确性

3. 功能适宜性

• 性能效率：评估与消耗的资源量相关的性能。

1. 时间行为

2. 资源利用率

3. 容量

• 兼容性：评估软件与其他产品共存和交换信息的能力。

1. 共存

2. 互操作性

• 交互能力：重点关注用户与软件交互的轻松程度和满意度。

1. 适当性可识别性

2. 易学性

3. 操作性

4. 用户错误保护

5. 用户参与度

6. 用户帮助

• 自我描述性

1. 可靠性：考察软件在一定条件下、一定时间内执行的能力。

2. 完美无缺

3. 可用性

4. 容错能力

5. 可恢复性

• 安全性：是指软件保护信息和数据的能力，使人员或系统仅被授予与其类型和授权相对应的访问权限。

1. 保密

2. 正直

3. 不可否认性

4. 真实性

5. 问责制

6. 反抗

• 可维护性：考虑更改软件以纠正错误、提高性能或适应环境变化的容易程度。

1. 模块化

2. 可重复使用性

3. 可分析性

4. 可修改性

5. 可测试性

• 灵活性：易于适应需求、上下文或系统环境的变化

1. 适应性

2. 可扩展性

3. 可安装性

4. 可替换性

• 安全：避免危及人类生命、健康、财产或环境的情况

1. 运营限制

2. 风险识别

3. 故障安全

4. 危险警告

5. 安全集成

两个可识别区域

ISO /IEC 25010 标准通过有用的分组概述了可能的质量特性。

在较高的层面上，我们可以将这些质量特征分为两个领域：

• 系统运行时的质量，即可观察到的行为。这对于用户的使用质量有着重大的影响。

• 系统在开发时的质量，对系统的开发者或维护者的使用质量有重大影响。

一个观点

目前发布的标准（ISO/IEC 25010:2023）缺乏实用性和实际适用性，因为它省略了可部署性、能源效率或代码质量等关键术语，而是侧重于用形容词而不是直观的名词来描述的系统属性。这种语言选择使得在日常工作生活中讨论和理解质量特征变得困难。

替代方案：arc42 的质量模型

由于 ISO 25010 缺乏实际指导和实用主义，arc42 提出了一种替代方法——arc42 质量模型“ Q42 ”。

arc42 质量模型“ Q42 ”是一种用于评估产品和系统质量的简单实用的方法。

首先了解利益相关者的期望和要求，以确定 8 个关键系统属性。这些属性旨在涵盖所需、期望或预期的 100 多个传统质量属性中的大部分。

软件计划中的八个典型利益相关者群体

在这种方法中，最初的重点是利益相关者。

他们已经确定了软件计划的典型利益相关者群体，这些群体通常对系统的质量有不同的期望：

• 用户期望该产品用户友好、可靠、易于使用且安全。

• 管理层致力于提高开发和运营成本的效率以及可靠性。

• 领域专家要求系统核心功能可靠、高效，并能灵活扩展新功能。

• 产品所有者寻求整合新功能的灵活性。

• 开发人员希望系统在代码维护方面灵活可靠、易于测试。

• 测试人员需要一个易于测试并提供一致结果的系统，并重视自动化和仪器仪表的灵活性。

• 管理员重视操作和维护的简便性、与其他系统的集成、安全性、执行环境的灵活性以及整体安全性。

• 其他人可能有此处未明确列出的其他期望。

系统的八个典型品质为

质量模型提出了涵盖系统质量的八个标签。

• #reliable：系统应该始终可用、强大、值得信赖，并且能够容忍故障并从中恢复，确保安全。

• #flexible：它应该在开发过程中以及不同的基础设施和运行时环境中具有适应性，允许更改、扩展和集成。

• #高效：系统期望能够快速执行并有效利用内存、CPU、线程、网络和其他资源，并且应该高效地可维护和可操作。

• #usable：它必须是用户友好的、视觉上有吸引力的并且适合用户的需求。

• #operable：系统应易于安装、操作、监控和维护，且运营成本合理。

• #suitable：它应该提供所需的特性、功能和职责。

• #secure：它应该确保数据的完整性、机密性和责任性，并防止未经授权的访问。

• #safe：它的设计目的应该是预防和管理故障，及时警告潜在风险并及早发现它们。

实践中的非功能性需求示例

前段时间，PO 来找我说：

“当用户打开前端时，它必须很快。因此它必须立即出现，以便用户可以开始填写表单。” 如果我们看一下 Q42，这个非功能性需求显然可以分配给顶级质量属性#efficient。如果我们查看当前分配给这个顶级组的品质，我们会发现效率，我们可以将其分配给这个“高级”非功能性需求。

当前分配的质量标记为高级组“高效”

但让我们分解一下产品所有者所期望的这种高级非功能性需求。

当我查看 PO 的声明时，我注意到以下部分：

• [...]打开前端，速度一定很快。[...]

• [...] 一定不能慢 [...] 立即到达 [...] 用户可以开始填写表单。

让我们在下一章中为此示例创建一个质量场景。👇

质量场景介绍

质量场景是一种伟大且经过验证的技术，可以使这些崇高而又不精确的期望变得清晰。

Len Bass 等人引入了质量场景。在伟大的软件架构著作《软件架构实践》中。

质量场景由以下元素组成：

• 刺激源：刺激必须有源。它一定来自某个地方。例如，来自一个人、一个系统或另一个参与者

• 刺激：到达系统的事件，例如用户操作、攻击、请求……

• 特定环境中的工件：

1. 刺激遇到一个特定的目标——工件。

2. 环境是场景发生的一组环境。

• 响应：响应是由于模拟到达而发生的活动

• 响应度量：当响应发生时，它应该以某种方式是可测量的，以便可以测试场景 - 也就是说，以便我们可以确定产品团队是否实现了它。

“快速打开前端的第一个视图”的示例质量场景 好吧，让我们尝试为提到的 PO 期望编写一个质量场景。

定义刺激源

此场景中的刺激源是“ Web 应用程序用户”。

定义刺激

刺激或事件是“通过https://my-web.app加载网络应用程序”。

定义工件及其环境

工件是“Web 前端”，环境是目标浏览器（例如基于 Chromium 的浏览器）

定义响应

响应是“浏览器加载并呈现 Web 前端”

定义响应措施

响应测量是（这就是明确性和可测量性的来源）：“视图端口内 Web 前端的主要内容在 2.5 秒或更短的时间内加载。”

---

随手关注或者”在看“，诚挚感谢！