[架构之路-114]-《软考-系统架构设计师》-软件架构设计-7-软件架构评估

Posted 2023-03-04 文火冰糖的硅基工坊

前言

第7节 软件架构评估

7.1 什么是架构评估/为什么要软件架构评估

在软硬件系统总体架构设计完成之后，为保证架构设计的合理性、完整性和针对性，从根本上保证系统质量，降低成本及投资风险，需要对总体架构进行评估。

7.2 软件架构评估的主要内容

（1）对软件的架构评估

　　对软件的架构评估，主要是根据具体的评估依据，对软件的质量进行评估。

• 看软件设计是否符合体系化设计原则；

• 产品中所开发的软件是否易于升级，

• 是否满足可扩展性强等软件的质量要求

（2）对硬件的架构评估

　　对硬件架构的评估，主要是根据具体的评估依据，

• 看研发的系统是否尽量采用了低功率处理器和较少的功耗部件，

• 是否满足低功耗的要求；

• 系统是否具有较大的基础资源空间以及资源扩展空间（如程序指令空间，内部外部存储空间等）；

• 是否易于运维管理；

• 研发产品的硬件是否易于升级，

• 是否满足可扩展性的要求等。

（3）对系统总体的架构评估

　　将以上软件架构和硬件架构综合起来进行评估，看研发的系统是否具备高可用性、高稳定性、高可靠性、高安全性、高性价比；是否具备良好的可扩展性等。

通过总体架构评估，达到增强各功能模块的集成度和联动性、提高总体性能的目的。

（4）架构评估主要侧重于以下几个方面：

• 　　架构设计是否符合架构设计模板？

• 　　架构设计是否符合《设计文件检查表》的要求？

• 　　通过架构设计，能否看到足够的系统表象以指引我们继续以后的设计活动？

• 　　架构设计是否组织性良好，并提供了简明的系统概要，背景信息，约束条件，和一个清晰的组织结构给所有下游的设计？

• 　　架构设计是否对可能的变化作了适应性设计？

• 　　架构设计是否位于详细设计和用户界面设计之上?

• 　　两个有相互依赖的架构设计图是否结合在一起？

• 　　系统架构，包括数据流、控制流、高层要件和接口，是否清楚地表现了？

• 　　是否忽略了细节的要件并将之遗留给以后的设计产物？

• 　　架构设计是否干净地分解了系统的顶级要件？

• 　　是否描述了系统的物理结构？

• 　　架构设计是否重视了不可避免的技术或其它方面的约束，即，这个架构能为目标环境而实现？

• 　　使用了反复设计，并选择了其中最好的尝试结果？对未选择的是否列出了理由？

• 　　对于问题域、用户界面、任务管理、数据管理，架构设计是否作了区分？

• 　　如果没有，那么缺少的部分有解释并通过验证了吗？

7.3 如何进行软架构评估

7.3.1 评估流程

评估工作按照时间的先后顺序可以分为五个阶段即：评估分析阶段、评估设计阶段、信息获取阶段、评估综合分析阶段、评估报告阶段。

架构评估的具体流程为：

（1）评估分析阶段

　　1）确定评估活动的目标、边界和重点

　　通过分析评估委托者的需求和主要用户关注的问题，确定评估活动的主要目标任务和服务对象，并明确评估重点回答的问题。

　　2）搜集现有的资料和信息，初步描述评估对象

　　收集现有的资料，包括：相关的评估报告和与评估对象相关的文献资料，形成对评估对象的初步印象。

　　3）评估者与委托者达成共识

　　就评估的目标、边界、重点、双方的责任等必要条件与委托者达成共识。

（2）评估设计阶段

　　1）确认评估问题

　　确认评估必须回答的问题和侧重回答的问题，并按重要性排序

　　2）设计评估框架：结构化评估

　　根据评估问题，设计评估的框架，主要包括评估的内容、重点、标准、指标等。

3）选择评估的方法和工具

　　根据评估活动的特点，选择适当的方法和工具，并调查获得这些方法和工具的途径。如果由于问题的特殊性以至于找不到成熟的方法，则应考虑现有的方法进行改进。

　　4）设计评估结果的表达方式

　　设计评估报告的内容和格式。

　　5）确定评估主持人及评估组的构成

　　根据评估活动的特点，确定评估主持人和评估组的构成，保证其能力、经验和专业知识结构适应评估设计的要求，并符合评估规范的回避原则。

　　6）制定评估活动的时间表

　　评估活动的时间表取决于以下两方面的因素：

　　委托者要求的完成评估的最后期限；

　　根据规范要求，评估各阶段、各步骤所需要的最少时间。如果上述两方面的要求相差较大，则需要启用变通条例。

　　7）确定评估设计方案

　　通过介绍评估方案进一步与委托者沟通，使委托者理解方案的主要特点，明确委托者必须提供的条件，同时向委托者说明方案存在的问题和涉及的风险，在进入下一个阶段之前，确定评估设计方案。

（3）信息获取阶段

　　1）评估数据信息的采集

　　按照评估设计的要求，进行各种数据信息的调查，包括案例调查、专题面访，实地调查及网上采集信息等，必要时需要选择咨询专家并进行相应的咨询。

　　2）数据信息的整理和检验

　　对采集的各类数据信息进行分类和整理、初步分析，为综合评估做准备。

　　3）必要的补充调查

　　在完成数据检验和初步分析之后，如果某些关键数据信息缺乏，不符合要求或难以确定其置信度，则需要采取补救措施，进行必要的补充调查。

（4）评估综合分析阶段

　　1）按评估问题组合信息，形成评估问题单元

　　根据评估设计中要回答问题和评估框架，对数据信息进行分组，形成评估问题单元。

　　2）问题判断

　　运用相应的评估方法，从回答问题的角度，对数据信息进行分析，分别形成对评估问题的判断。

　　3）综合分析评价

　　个体评估：在对评估问题判断的基础上，运用综合评估方法对个体进行分析评价。

　　群体评估：除了对个体进行综合分析评价以外，还要运用适当的方法，对群体进行分类、分级或排序。

　　4）形成评估初步结论

　　个体评估：评估初步结论一般包括关于评估对象各方面的评估意见和整体评估结论。

　　群体评估：评估初步结论首先是关于被评估对象的分类、等级划分或排序表，根据评估合同的要求，有时也要提供全部或部分个体的评估结论。

　　5）形成正式评估结论

　　个体评估：针对评估要回答的重点问题，对评估初步结论进行确认或修正，形成正式评估结论。

　　群体评估：重点对被评估的对象的分类、等级划分或排序表进行核查、验证和必要的调整。

（5）评估报告阶段

　　1）撰写评估报告初稿

　　根据评估规范的规定和评估设计中关于评估报告的内容及格式的具体要求，撰写评估报告初稿。

　　2）讨论并修改评估报告初稿

　　在评估组内对评估报告初稿中的主要结论进行讨论，确定修改的方案。在制定评估活动的时间表时，安排适当的时间用于修改评估报告初稿。

　　3）评估组确认提交的正式评估报告版本

　　根据质量控制标准对拟提交的评估报告进行检查，确定正式评估报告版本。

　　4）提交正式评估报告

　　确认后的正式评估报告版本，由评估机构负责人和该评估项目主持人签字并盖章后提交给委托者。

　　5）回答有关评估报告的提问

　　在提交评估报告后，在一段时间内，准备回答有关评估报告的提问。

　　6）整理和保存评估档案

7.3.2 质量保证

　　评估质量保证以质量控制为核心，以本单位的全面质量控制为基础，以外部的监督检查为补充。

　　评估内部质量控制系统由评估规范、实施程序、奖励处罚制度和其他保证措施组成。评估质量控制既涉及严格的技术层面（数据采集和方法的选取、对相关事实的分析、评估报告的撰写等），又涵盖职业道德、行为规范等非技术层面。

　　评估的质量控制覆盖从评估准备到提交评估报告的全过程，重点控制以下环节：

　　（1）合同中关于评估的内容

　　评估合同/协议是评估活动的基础，也是评估项目质量控制的重要依据，必须保证合同或协议内容全面，委托方和受托方双方约定的表达清楚，无疑义。

　　（2）委派项目主持人

　　项目主持人是否称职对于保证项目的质量十分重要，评估机构在委派项目主持人时，要认真考察其职业道德和业务能力，并确认是否符合问题原则?

　　（3）评估方案执行

　　评估主持人负责对参加评估人员进行关于评估方案的培训，监督每个环节，每个评估人员的执行情况，并对执行过程中的薄弱环境进行分析和采取补救措施，负责修正评估方案。

　　（4）评估结论的检查与复核

　　在正式提交评估报告之前，评估机构应对评估的主要结论进行检查和复核。对评估结论的检查与复核的重点内容主要包括：

　　（5）是否符合评估标准

　　检查评估结论及依据是否符合评估方案中设定的标准，尤其要检查不同评估人员掌握的评估标准能否保持一致，评估质量能否达到要求，尽可能减小人为误差。

　　（6）评估依据是否充分

　　目前还没有公认的办法用来直接检测评估依据的充分性，但在正式提交评估报告之前，评估者必须做出判断，所提供的依据能否支撑评估结论。一般来说，如果采用多渠道、多角度采集和分析信息，评估依据的充分性可以得到改善?

　　（7）评估结论是否可靠

　　检查评估结论是否可靠的重要途径是检查评估活动的可重复性，即产生同样结论的过程是否重复。例如：采用同样的问卷，用同样的标准选择另一批咨询专家，采用同样的问卷征询专家的意见，采用同样的方法对专家的意见进行分析综合，是否可获得基本一致的评估结论。如果上述两次评估活动的结论差异很大，说明评估结论是否可靠较差，须谨慎使用。

7.3.3 重点关注方向

• 关注风险点：对关键质量有较大风险的因素

• 关注敏感点：对关键质量影响权重较大的因素

• 关注权衡点：对关键质量有影响的相互制约因素的权衡

评估方法：

• 问卷调查、检查表评估

• 结构化度量式评估

• 场景式的评估

7.3.4 场景式的评估方法

（1）SAAM

SAAM （Software Architecture Analysis Method）是卡耐基梅隆大学软件工程研究所(SEI at CMU)的Kazman等人于1993年提出的一种非功能质量属性的体系结构分析方法，是最早形成文档并得到广泛使用的软件体系结构分析方法。

最初它用于比较不同的软件体系的体系结构，以分析SA的可修改性，后来实践证明也可用于其他的质量属性如可移植性、可扩充性等，发展成了评估一个系统的体系结构。

SAAM的目标是对描述应用程序属性的文档，验证基本的体系结构假设和原则。此外，该分析方法有利于评估体系结构固有的风险。SAAM指导对体系结构的检查，使其主要关注潜在的问题点，如需求冲突，或仅从某一参与者的观点出发的不全面的系统设计。SAAM不仅能够评估体系结构对于特定系统需求的使用能力，也能用来比较不同的体系结构。

SAAM用于体系结构的最后版本，但早于详细设计。体系结构的描述形式应当被所有参与者理解。功能、结构和分配被定义为描述体系结构的三个主要方面。

SAAM的主要输入问题是问题描述、需求声明和体系结构描述。如下图所示描绘了SAAM分析活动的相关输入及评估过程。

（2）ATAM

ATAM是评价软件构架的一种综合全面的方法。这种方法不仅可以揭示出构架满足特定质量目标的情况，而且（因为它认识到了构架决策会影响多个质量属性）可以使我们更清楚地认识到质量目标之间的联系——即如何权衡诸多质量目标。

备注：性能指标是在功能性需求基础之上，增加了一些量化的约束指标，就得到了性能性需求。

质量属性本身是没有优先级的，质量属性的优先级是在场景下产生的。

不同的场景，对不同的质量属性有不同的要求，比如，有些场景对延时的要求比较高，有些场景对安全性要求比较好，而有些场景对吞吐量或吞吐率的要求比较高，有些场景对可可靠性的要求比较高。

没有场景，空谈软件质量属性，是空中楼阁，没有基础和支撑。

因此，不同的场景，其软件质量指标可能是冲突的，这就需要进行综合与折中。因此，软件质量的属性最终取决于场景的优先级。