文章目录
- 壹、软件评估方法分类与质量属性场景分析
-
- [一、 软件架构评估方法分类](#一、 软件架构评估方法分类)
- 二、质量属性场景的六个标准化要素
- 三、不同方面的场景分析
- 贰、软件评估方法
壹、软件评估方法分类与质量属性场景分析
软件架构评估方法体现了从定性到定量、从主观到客观的演进过程。
- 早期的调查问卷方法虽然简单易行，但结果主观性强；
- 基于场景的方法针对性更强，但仍有一定主观色彩；
- 基于度量的方法则提供了客观精确的评估结果。
这种演进反映了软件工程学科的成熟，从经验驱动逐步转向数据驱动。
另外，质量属性场景分析构建了一个标准化的描述框架 。
通过刺激源、刺激、环境、制品、响应、响应度量这六个要素，将复杂的系统行为分解为可理解、可分析的组件。
这种标准化方法确保了不同评估者能够使用统一的语言和标准，提高了评估结果的一致性和可比性。同时，场景分析方法将抽象的质量需求转化为具体的测试场景，使得架构师能够在设计阶段就验证架构对各种质量属性的支持程度。
一、 软件架构评估方法分类
软件架构评估方法按照分析深度和客观程度分为三大类，每类方法适用于不同的项目阶段和评估目标 。
| 评估方法 | 定义与特点 | 具体示例 | 适用场景 |
|---|---|---|---|
| 基于调查问卷 | 通用性强，适用于广泛收集意见 评估者只需对架构粗略了解 | 新软件产品概念设计阶段向潜在用户发放问卷 了解功能需求、界面风格等方面的期望 | 项目早期，架构了解有限 需要广泛收集各方看法 |
| 基于检查表 | 针对特定领域，评估者无限制 实施阶段适中，具有主观性 | BIM项目中依据特定检查表 核查模型是否符合行业规范和标准 | 特定领域规范核查 标准化评估场景 |
| 基于场景 | 针对特定系统，要求中等程度了解 实施阶段为中期，主观性较强 | 电商系统设定用户高并发下单、库存不足等场景 评估系统架构应对能力 | 项目中期，特定系统深入评估 发现实际使用中的问题 |
| 基于度量 | 通用性或特定领域，需精确了解架构 实施阶段适中，相对客观 | 测量系统响应时间、吞吐量等性能指标 评估网络架构优劣 | 需要客观精确评估结果 评估者对架构有深入了解 |
二、质量属性场景的六个标准化要素
质量属性场景分析通过六个标准化要素，将抽象的质量需求转化为具体可测试的场景。
| 场景要素 | 定义与作用 | 具体示例 | 分析重点 |
|---|---|---|---|
| 刺激源 | 产生刺激的源头 影响系统行为的外部因素 | 电商APP用户点击"立即购买"按钮 物流系统向电商系统发送发货状态更新 | 识别所有可能的刺激来源 区分内部和外部刺激源 |
| 刺激 | 到达系统的具体条件 触发系统响应的具体事件 | 用户点击"立即购买"按钮操作 特定时间点系统接收新订单数据 | 明确刺激的具体形式和频率 分析刺激的时间特性 |
| 环境 | 刺激发生时的系统状态 影响响应的环境条件 | 双11大促期间高并发状态 平常时段正常运行状态 | 考虑不同环境下的系统表现 识别环境变化对响应的影响 |
| 制品 | 被刺激影响的对象 系统的重要组成部分 | 订单处理模块、整个购物流程系统 视频播放模块、用户界面 | 确定影响范围和程度 分析制品间的依赖关系 |
| 响应 | 系统对刺激的反应 采取的具体行动 | 进行库存检查、生成订单操作 视频停止播放、显示暂停图标 | 评估响应的正确性和效率 分析响应的完整性 |
| 响应度量 | 衡量响应效果的指标 量化的评估标准 | 订单生成时间是否在1秒内完成 点击暂停到实际停止播放时间<0.5秒 | 建立可测量的评估标准 确定度量的精度要求 |
三、不同方面的场景分析
1、可用性
可用性场景分析关注系统持续稳定提供服务的能力，通过具体场景验证系统的可用性设计。
| 场景要素 | 具体内容 | 实际示例 | 评估指标 |
|---|---|---|---|
| 刺激源 | 系统内部故障 外部攻击或误操作 | 服务器硬件老化导致故障 用户频繁错误输入导致系统异常 | 故障源识别准确性 故障类型覆盖度 |
| 刺激 | 疏忽、错误、崩溃、时间因素 | 运维人员配置错误、程序逻辑错误 软件闪退、长时间高负载运行 | 刺激类型分类完整性 触发条件明确程度 |
| 环境 | 正常操作环境 降级模式运行 | 日常业务正常运行状态 电商系统高并发时关闭非核心功能 | 环境状态转换机制 降级策略有效性 |
| 制品 | 系统处理器、通信信道 持久存储器、进程 | CPU故障影响运算、网络中断 硬盘损坏致数据丢失、进程崩溃 | 制品故障影响范围 关键制品识别准确性 |
| 响应 | 检测事件、记录通知 禁止错误源、继续运行 | 向运维人员发送警报邮件 发现恶意IP后将其封禁 | 响应时间 响应措施有效性 |
| 响应度量 | 可用时间百分比 故障修复时间 | 每月99.9%时间可用 平均修复时间不超30分钟 | 可用性目标达成率 修复效率指标 |
2、可修改性
可修改性场景分析评估系统适应变化的能力，通过变更场景验证架构的灵活性。
| 场景要素 | 具体内容 | 实际示例 | 评估指标 |
|---|---|---|---|
| 刺激源 | 最终用户需求变更 开发人员优化需求 系统管理员配置调整 | 电商APP用户希望增加分组购物车功能 开发人员发现代码性能问题需优化 | 需求来源多样性 变更请求合理性 |
| 刺激 | 增加、删除、修改功能 调整质量属性和容量 | 社交软件删除某冷门功能 在线办公软件提升文件存储容量 | 变更类型覆盖度 变更复杂度评估 |
| 环境 | 设计时、编译时 构建时、运行时 | 设计时优化架构、编译时调整代码语法 构建时增减组件、运行时修复紧急漏洞 | 不同阶段修改便利性 环境切换成本 |
| 制品 | 用户界面、平台 环境、交互系统 | UI改版、底层架构升级 服务器迁移、对接新支付渠道 | 制品修改影响范围 制品间耦合程度 |
| 响应 | 定位改动位置、确保功能不受影响 全面测试、部署更新 | 修改网站登录功能不影响商品浏览 修改后进行完整的回归测试 | 修改准确性 影响控制效果 |
| 响应度量 | 成本、努力、资金投入 对其他功能的影响程度 | 更改Web界面接口在2人周内完成 评估修改对订单处理效率的影响 | 修改成本控制 质量属性影响评估 |
3、性能
性能场景分析关注系统的响应能力和处理效率，通过负载场景验证系统性能表现。
| 场景要素 | 具体内容 | 实际示例 | 评估指标 |
|---|---|---|---|
| 刺激源 | 用户请求 其他系统触发 | 搜索引擎用户输入关键词搜索 物流系统发送订单状态更新消息 | 请求来源分布 触发频率统计 |
| 刺激 | 定期事件、随机事件 偶然事件到达 | 系统定时数据备份任务 用户随机发起在线客服咨询 电商平台突发限时抢购活动 | 事件类型分类 负载模式识别 |
| 环境 | 正常模式 超载模式 | 在线教育平台日常学习时段 双11期间电商平台高并发状态 | 负载水平分级 环境切换阈值 |
| 制品 | 整个系统 | 前端页面响应、后端数据处理 数据库查询、网络传输 | 系统整体性能 各组件性能贡献 |
| 响应 | 处理刺激 改变服务级别 | 社交软件处理动态发布流程 视频直播平台降低分辨率保证流畅 | 处理效率 服务质量调整策略 |
| 响应度量 | 等待时间、期限、吞吐量 抖动、缺失率、数据丢失率 | 网页加载等待时间<3秒 支付确认必须在3秒内完成 Web服务器每秒处理1000个HTTP请求 | 性能指标达标率 服务质量稳定性 |
4、可测试性
可测试性场景分析评估系统测试的便捷程度，通过测试场景验证系统的可测试性设计。
| 场景要素 | 具体内容 | 实际示例 | 评估指标 |
|---|---|---|---|
| 刺激源 | 开发人员、增量开发人员 系统验证人员、客户验收人员 | 开发人员对新算法模块进行单元测试 客户按合同要求进行验收测试 | 测试人员角色覆盖 测试责任分配清晰度 |
| 刺激 | 已完成的分析、架构、设计 类和子系统集成、交付系统 | 架构设计完成后测试不同负载下性能 系统交付后进行验收测试 | 测试阶段完整性 测试触发条件明确性 |
| 环境 | 设计时、开发时 编译时、部署时 | 设计文档评审和走查 开发过程单元测试和代码审查 部署前环境兼容性测试 | 不同环境测试便利性 测试环境搭建效率 |
| 制品 | 设计文档、代码段 完整应用 | 架构设计文档、接口设计文档 单个函数或类的单元测试 整个软件应用系统测试 | 制品测试覆盖度 测试粒度适当性 |
| 响应 | 提供状态值访问、计算值获取 准备测试环境 | 测试计数器功能时获取当前值 数据库功能测试时准备测试数据 | 测试数据可访问性 测试环境准备完整性 |
| 响应度量 | 代码覆盖率、故障概率 测试执行时间、依赖复杂度 | 单元测试80%代码覆盖率 测试人员20分钟内完成代码单元测试 | 测试质量指标 测试效率指标 |
5、易用性
易用性场景分析关注用户体验，通过用户操作场景验证系统的易用性设计。
| 场景要素 | 具体内容 | 实际示例 | 评估指标 |
|---|---|---|---|
| 刺激源 | 最终用户 | 手机APP使用者 办公软件新用户 | 用户类型多样性 用户技能水平分布 |
| 刺激 | 学习系统特性、有效使用系统 降低错误影响、适配系统、系统满意 | 新用户学习绘图软件工具使用 用户快速完成文档编辑任务 财务软件提供转账撤销功能 | 用户需求覆盖度 使用场景完整性 |
| 环境 | 系统运行时 配置时 | 在线购物平台购物流程体验 设置电脑桌面背景和快捷键 | 不同环境易用性 配置操作便利性 |
| 制品 | 整个系统 | 界面设计、功能模块 交互逻辑、帮助系统 | 系统组件易用性 整体用户体验 |
| 响应 | 提供学习支持、优化界面布局 错误恢复、个性化配置 | 新游戏新手引导关卡 常用功能聚合展示、撤销操作 多语言界面支持 | 支持功能有效性 用户体验改善程度 |
| 响应度量 | 任务时间、错误数量 用户满意度、成功操作比例 | 文件查找打开时间<30秒 新用户学习系统时间不超过2小时 | 易用性指标达标率 用户学习成本控制 |
6、安全性
安全性场景分析关注系统安全防护能力，通过攻击和防护场景验证系统安全性设计。
| 场景要素 | 具体内容 | 实际示例 | 评估指标 |
|---|---|---|---|
| 刺激源 | 内部/外部个人或系统 已授权/未授权用户 | 外部攻击者虚假身份登录企业系统 企业员工超权限访问敏感数据 黑客试图窃取大量客户数据 | 威胁来源识别准确性 攻击者类型覆盖度 |
| 刺激 | 显示数据、改变/删除数据 访问系统服务、降低可用性 | 非法查看患者病历信息 篡改电商系统商品价格 DoS攻击使网站服务器瘫痪 | 攻击类型分类完整性 威胁场景覆盖度 |
| 环境 | 在线/离线、联网/断网 有防火墙/直接连网 | 在线时面临网络攻击风险 防火墙保护vs直接连网暴露 | 不同环境安全风险 防护措施有效性 |
| 制品 | 系统服务 系统中的数据 | 网站登录服务、支付服务 用户信息、业务数据 | 资产价值评估 保护对象重要性 |
| 响应 | 身份认证、访问控制 数据加密、攻击检测 | 用户名密码、指纹识别认证 敏感数据哈希加密存储 异常流量检测和IP封禁 | 防护措施覆盖度 安全响应及时性 |
| 响应度量 | 成功防护概率、攻击成本 检测可能性、恢复能力 | 信用卡支付99.999%安全性 攻击者突破防护所需时间成本 | 安全指标达标率 安全投资回报率 |
贰、软件评估方法
软件架构评估方法体现了从单一属性关注到多属性权衡的演进过程。SAAM最初专注于可修改性评估，就像早期的质量检测只关注产品是否能用；ATAM发展为多属性权衡分析，如同现代质量管理需要综合考虑性能、安全、成本等多个维度；CBAM进一步引入经济模型，体现了从技术导向向商业价值导向的转变。
1、软件架构评估方法发展历程
软件架构评估方法按照发展时间和关注重点，形成了三个主要的发展阶段。
| 评估方法 | 发展脉络与特点 | 关注重点 | 典型应用场景 |
|---|---|---|---|
| SAAM | 最早形成文档的架构分析方法 为后续方法发展奠定基础 | 初期聚焦可修改性 后扩展到可移植性、可扩充性 | 在线购物系统需求变更评估 系统功能扩展可行性分析 |
| ATAM | 在SAAM基础上发展而来 继承理念并进行拓展 | 性能、实用性、安全性、可修改性 多属性权衡分析 | 在线教育平台多场景评估 高并发系统质量属性平衡 |
| CBAM | 在ATAM基础上建立 构建软件"经济"模型 | 成本效益分析 经济可行性评估 | 企业级系统架构选型 投资回报率驱动的架构决策 |
2、SAAM方法详解
SAAM（Software Architecture Analysis Method）专注于可修改性评估，通过场景分析验证架构的灵活性和适应性。
| 实施阶段 | 主要活动 | 具体示例 | 关键输出 |
|---|---|---|---|
| 问题描述 | 明确系统要解决的问题 定义业务目标和用户需求 | 开发在线购物系统：商品展示、交易功能 用户需求：便捷购物流程、快速响应 | 问题定义文档 业务目标清单 |
| 需求分析 | 梳理功能需求和非功能需求 深入分析问题本质 | 功能需求：商品搜索、订单管理 非功能需求：性能要求、安全性要求 | 需求规格说明 约束条件清单 |
| 架构设计 | 确定组件划分和交互方式 制定架构解决方案 | 采用微服务架构实现购物系统 各功能模块独立部署与交互 | 架构设计文档 组件接口定义 |
| 场景开发 | 开发反映系统使用的场景 覆盖可能面临的变化 | 高并发下单场景、商品信息修改场景 促销活动场景、系统升级场景 | 场景描述集合 变更需求清单 |
| 场景评估 | 评估架构对各场景的支持 识别潜在问题和风险 | 高并发下单时系统稳定性评估 订单处理与库存更新协调性分析 | 场景评估报告 风险识别清单 |
| 总体评估 | 综合评估结果比较方案 选择最优架构设计 | 比较不同架构在各场景下表现 确定最符合需求的架构方案 | 架构评估报告 推荐架构方案 |
3、ATAM方法详解
ATAM（Architecture Tradeoff Analysis Method）在SAAM基础上发展，专注于多质量属性的权衡分析。
| 分析阶段 | 核心活动 | 具体示例 | 分析重点 |
|---|---|---|---|
| 场景和需求收集 | 与利益相关者沟通收集场景 明确需求、约束和环境 | 在线教育平台：大量学生同时学习场景 教师上传课程资料场景 | 覆盖所有关键使用场景 识别系统约束条件 |
| 架构视图描述 | 从多角度描述软件架构 分析场景实现方式 | 逻辑视图：课程管理模块、用户管理模块 物理视图：服务器部署、网络架构 | 架构完整性验证 场景可实现性分析 |
| 属性模型构造 | 运用理论分析质量属性 识别敏感点和权衡点 | 排队论分析系统性能和吞吐量 数据库设计对性能和安全性敏感 | 质量属性深度分析 架构敏感点识别 |
| 权衡折中 | 平衡冲突的质量属性 制定架构决策 | 在线教育平台安全性与性能平衡 确保学习体验不受安全策略影响 | 质量属性优先级确定 折中策略制定 |
ATAM质量效用树分析：
| 质量属性 | 具体场景 | 权重评估 | 实现策略 |
|---|---|---|---|
| 性能 | 1000名学生同时在线学习 视频播放响应时间<2秒 | 高优先级 权重：30% | 内容分发网络(CDN) 负载均衡、缓存优化 |
| 可修改性 | 新增课程类型功能 2周内完成开发部署 | 中等优先级 权重：25% | 模块化设计 微服务架构、API标准化 |
| 安全性 | 学生个人信息保护 防止数据泄露99.9% | 高优先级 权重：25% | 数据加密、访问控制 身份认证、审计日志 |
| 可用性 | 系统全年可用性99.5% 故障恢复时间<5分钟 | 中等优先级 权重：20% | 冗余部署、健康检查 自动故障转移 |
4、CBAM方法详解
CBAM（Cost Benefit Analysis Method）在ATAM基础上建立，构建软件架构的经济评估模型。
| 分析维度 | 评估内容 | 具体示例 | 决策指标 |
|---|---|---|---|
| 成本分析 | 开发成本、维护成本 部署成本、培训成本 | 微服务架构开发成本：500万元 单体架构开发成本：300万元 年度维护成本：微服务80万，单体120万 | 总拥有成本(TCO) 成本分解结构 |
| 效益分析 | 业务价值、用户体验 系统性能、可扩展性 | 微服务架构支持快速功能迭代 预计年收入增长：200万元 用户满意度提升：15% | 投资回报率(ROI) 净现值(NPV) |
| 风险评估 | 技术风险、市场风险 实施风险、维护风险 | 微服务架构技术复杂度高 团队学习成本：50万元 实施失败概率：20% | 风险调整收益 风险缓解成本 |
| 决策支持 | 多方案对比分析 最优方案推荐 | 方案A：3年ROI 35%，风险中等 方案B：3年ROI 25%，风险较低 推荐方案A | 综合评分模型 敏感性分析 |
CBAM经济模型示例：
| 架构方案 | 初期投资 | 年度运营成本 | 年度收益 | 3年净现值 | 风险调整后NPV |
|---|---|---|---|---|---|
| 微服务架构 | 500万 | 80万 | 280万 | 320万 | 256万 |
| 单体架构 | 300万 | 120万 | 200万 | 180万 | 162万 |
| 混合架构 | 400万 | 100万 | 240万 | 220万 | 198万 |