架构质量的内外之分与质量保障的意义

架构质量分内部质量和外部质量：开发态（静态）软件架构难以在真实环境中运行，其质量属于内部质量，包含架构模型、数据、描述文档和视图本身的质量；运行态（动态）软件架构的质量是外部质量，即基于该架构开发出的系统所表现出的性能、可靠性、安全性等。软件架构质量保障之所以重要，源于四点理由。一是质量问题贯穿软件工程学科发展始终——从Parnas 1972年提出模块化与信息隐藏、到Stevens等1974年引入耦合聚合概念评估程序分解，学术界和工业界早已认识到架构与质量属性密不可分。二是”问题发现得越早，解决代价越小”——架构是早期设计阶段的产物，决定着配置、进度预算、性能指标、开发小组结构、文档组织、测试维护等方方面面，不恰当的架构会给项目带来灾难性后果，无法弥补的性能、可靠性、安全性缺陷往往根植于架构层面而非编码层面。三是架构自身有很高的质量需求，但仅仅在需求中写”系统应该健壮”“应该易于更改”这类空泛描述并不足以判断架构是否合格，必须在架构描述中把这些要求说清楚，否则会有不同解释、埋下质量隐患。四是架构质量保障会带来诸多附带收益：把利益相关者召集到一起、加深彼此理解；为相互冲突的质量目标划定优先级；督促架构师把架构文档写得更详细（例如性能调查会倒逼补齐运行时任务/进程交互文档）；发现项目间交叉重用的可能性；提高架构实践者水平（开发组织逐渐能预判评估会问什么，从而主动调整）；有益于组织未来项目（如ATAM的质量属性探测问题列表本身就是公开可参照的）。需要注意，架构质量保障只是最终系统质量保障的一个环节，架构本身不能保证系统一定满足用户需求——具体设计、实现、测试、管理不当同样会消减架构带来的好处。