软件系统质量属性一览表

📊 一、整体结构分析

该表格分为三列:

表格

列名内容说明
属性质量属性的大类(如“开发期质量属性”、“运行期质量属性”)
子属性每个大类下的具体质量特性(如易理解性、可扩展性、性能等)
作用及要点对每个子属性的定义或解释,说明其含义和关注点

表格按时间维度划分为两大块:

  1. 开发期质量属性 —— 关注软件开发过程中的可维护性、可测试性等。
  2. 运行期质量属性 —— 关注系统上线后在实际使用中的表现,如性能、安全性、可用性等。

🔍 二、逐项详解


✅ 第一部分:开发期质量属性

这些属性主要影响开发效率、成本控制、后期维护难度

表格

子属性作用及要点
易理解性指设计被开发人员理解的难易程度 → 影响团队协作、新人上手速度
可扩展性软件因适应新需求或变化而增加新功能的能力 → 也称“灵活性”,是架构设计的核心目标之一
可重用性指重用软件系统或某一部分的难易程度 → 提高开发效率,降低重复劳动
可测试性对软件测试以证明其满足需求规范的难易程度 → 直接影响测试成本和缺陷发现率
可维护性当需要修改缺陷、增加功能、提高质量时,识别修改点并实施修改的难易程度 → 综合体现系统长期生命力

💡 注意:“可维护性”是一个综合性指标,常包含易理解性、可修改性、可测试性等。


✅ 第二部分:运行期质量属性

这些属性直接决定用户体验、系统稳定性、业务连续性

表格

子属性作用及要点
可移植性将软件从一个运行环境转移到另一个不同环境的难易程度 → 如跨平台、云迁移能力
性能系统及时提供相应服务的能力,如速度、吞吐量、容量等 → 用户最直观的感受之一
安全性同时兼顾向合法用户提供服务 + 防止非授权访问 → 包括认证、授权、加密、审计等
可伸缩性用户数/数据量增长时,维持高服务质量的能力 → 常用于分布式系统、微服务架构
互操作性与其他系统交换数据和相互调用服务的难易程度 → API 设计、协议兼容性的关键
可靠性在一定时间内持续无故障运行的能力 → MTBF(平均无故障时间)衡量
可用性系统在一定时间内正常工作的时间所占比例 → 通常用“几个9”表示(如99.9%)
鲁棒性在非正常情况下(非法操作、硬件故障等)仍能正常运行的能力 → 又称“健壮性”或“容错性”

💡 “鲁棒性” ≠ “可靠性”:

  • 可靠性:不出错;
  • 鲁棒性:出错了也能扛住、不崩溃。

🧩 三、重要概念辨析

表格

概念区别说明
可扩展性 vs 可伸缩性可扩展性:功能层面——能否方便地加新功能可伸缩性:性能层面——能否应对更多用户/数据
可靠性 vs 可用性 vs 鲁棒性可靠性:少出错可用性:停机时间短鲁棒性:出错也不崩
可维护性 vs 易理解性易理解性是基础,可维护性是结果可维护性还包括可修改性、可测试性等

四、应用场景与意义

这张表适用于:

  • 软件架构师:在设计初期权衡各项质量属性,做出取舍(Trade-off)。
  • 项目经理:评估项目风险、制定测试计划、安排运维资源。
  • 产品经理:明确非功能性需求(NFR),避免只关注功能忽略质量。
  • 考生备考:软考(系统架构设计师、系统分析师)、PMP、CMMI 等考试中高频考点。

📌 五、典型考题示例(软考风格)

【单选题】以下哪项不属于运行期质量属性?
A. 性能
B. 可维护性
C. 安全性
D. 可用性
✅ 正确答案:B. 可维护性(属于开发期)

【多选题】哪些属性会影响系统的“用户体验”?
A. 性能
B. 可用性
C. 可移植性
D. 鲁棒性
✅ 正确答案:A、B、D


✍️ 六、总结评价

这张表格内容完整、分类清晰、定义准确,是对软件质量属性的经典归纳,符合 ISO/IEC 25010 标准(系统与软件质量模型)的核心思想。

✔️ 结构合理
✔️ 术语规范
✔️ 实用性强
✔️ 适合教学、考试、工程实践参考


💡 七、延伸建议

如果你想深入学习软件质量属性,可以进一步研究:

  • ISO/IEC 25010 标准(国际通用软件质量模型)
  • ATAM(Architecture Tradeoff Analysis Method) —— 架构权衡分析方法
  • 质量属性场景(Quality Attribute Scenarios) —— 如何量化描述质量需求
  • 架构模式如何支持特定质量属性(如微服务→可伸缩性;缓存→性能;冗余→可靠性)