软考高级软件架构师论文——论软件架构评估

摘要

        我所在单位是某商业银行，2019年1月我行决定开发全新一代绩效考核平台系统，我担任本次系统开发的架构师，主要负责整个系统的架构设计工作。该系统既满足内控管理的绩效考核，又满足银行粉丝客户参与营销的综合性绩效平台，是银行应对互联网金融变革和笃行普惠金融的重要系统。本文结合我的实践，以绩效考核平台系统建设为例，论述软件系统架构评估。首先分析了软件架构评估所普遍关注的质量属性并阐述其具体含义，然后详细说明本次项目软件架构评估采用的ATAM评估方法、实施过程，评估小组经过对系统中的风险点、敏感点、权衡点分析后生成质量效用树。通过ATAM架构评估保证了绩效考核平台系统的顺利完成，目前系统已经稳定运行1年多，得到了领导、员工、客户的一致好评。

正文

        我所在的单位是珠三角地区某城市商业银行，机构覆盖全国多个省、直辖市。目前银行业正面临互联网金融浪潮的冲击，银行需要积极转型、自我变革，不仅要服务好优质客户还要抓住普通大众客户，发展新零售拓展小微企业客户业务成为当下银行的战略要点，绩效考核将成为银行战略转型的有效指挥棒。正是在这一背景下我行提出建设全新一代绩效考核平台，既对传统的绩效考核做出调整，又结合联网化的“粉丝及员工”理念，搭建多维度、多渠道、多群体的绩效考核平台。银行绩效考核涵盖传统存贷款考核、产品营销考核、专项考核几大方面，对银行员工管辖的存贷款计价模型计算员工创造利润、产品营销结果、专项产品达标情况等可量化的指标来考核员工，对客户为银行推销的产品进行量化统计并给予奖励，银行总部通过不同的计价系数和组合策略引导全体员工向政策目标迈进，将绩效考核形成指挥棒。

        本次绩效考核平台系统采用j2EE技术开发的B/S架构系统，使用SOA架构设计方法，数据库使用MySql， Redis内存数据库，服务器操作系统采用Redhat7.2等。

        软件质量特性是软件架构设计关注的一个重点，在软件架构评估中的质量属性包含性能、可用性、安全性、可修改性、可靠性、易用性、可测试性等，其中前4个质量属性是质量效应树的重要组成部分。具体含义：

        1、性能是指系统相应能力，即系统多久才能对某个事件做出响应，或在某段时间内能处理事件的个数；

        2、可用性是指系统能正常运行的时间比；

        3、安全性是指系统除了能对合法用户提供服务的同时还能阻止非授权用户使用的企图或拒绝服务能力；

        4、可修改性是指能快速地并以较高性价比对系统进行变更地能力；

        5、可靠性是指软件系统在应用或错误面前、在意外或错误使用情况下保持系统地功能特性地基本能力；

        6、易用性是衡量一个用户使用软件产品完成指定任务地难易程度；

        常用地软件架构评估有基于问卷调查地评估方式、基于度量地评估方式、基于场景地评估方式。基于问卷调查方式具有主观性不太适合本项目，基于度量地方式虽然评价比较客观，但需要评价者对系统架构有精确地了解，所以也不太适合本项目，而基于场景地方式要求评估者对系统中等了解，评价比较主观，故本项目采用了基于场景地评估方式。基于场景地评估方式又分为架构分析法SAAM、架构权衡分析法ATAM和成本效益分析法CBAM，本项目中根据不同质量属性使用了ATAM作为系统架构评估地方法。

        在进行架构评估时，按照需要确定了评估参与者，评估小组有总行业务人员、支行行长代表、主办会计代表、客户经理、和柜员代表、客户代表等组成；项目决策组成员包含总行行长、首席信息官、业务部主管、系统架构师、项目经理、员工代表等组成。架构涉众包含还包含项目开发人员、测试人员、运维人员等。架构评估经历了描述和介绍阶段、调查和分析阶段、测试阶段、报告阶段。下面我分别对者四个阶段进行介绍：

        1、描述和介绍阶段，由于参与评估地人员有部分是对ATAM评估不了解，我首先介绍了ATAM架构评估地方法和目的。项目决策组行长、业务主管等人介绍了绩效考核平台地业务动机。最后作为项目系统架构的我描述了整个系统采用SOA架构实现，将系统划分为若干独立子系统，各个子系统包含的功能及讲解，如何与银行内的其他系统协作，这么进行安全规划。

        2、在调查分析阶段，结合场景不同角色的需求方都基于各自立场提出了相关需求，需求及质量场景如下：

        A）在正常网络负载情况下，系统必须在2s内响应用户操作请求。

        B）服务端与客户端、微信端的交互，使用ssl证书，实现https安全加密访问。

        C）系统能够抵御99.99%的黑客攻击。

        D）微信端客户绑定认证使用客户在银行预留的身份证号，姓名，手机号等信息。

        E）支行用户和客户代表提出WEB页面要简洁美观，各功能简单易用，尽可能让用户少输入数据项。

        F）网络失效后，系统需要在1分钟内发现错误并启用备用网络。

        G）主机房断电后，必须在3秒内将请求重定向到灾备机房服务器。

        H）对查询请求处理时间的要求将影响到系统的集群方式和处理 过程的设计。

        I）微信端的异常和员工的操作失误，不影响系统功能的正常使用。

        J）科技信息部提出的更改系统加密的级别将对安全性和性能产生影响。

        K）更改系统的WEB页面必须在2人天内完成，修改绩效考核计算规则必须在1周内完成。

        L）目前对系统使用“统一的绩效认领中心”业务逻辑描述尚未达成共识，这可能导致部分业务功能模块的重复和绩效计算不准确，影响系统的可修改性。

        经过分析总结我们获得了系统质量效用树，属于性能的有A，属于可用性的有F和G，属于安全性的有B和G，属于可修改性的有K，属于可靠性的有I，属于易用性的有E。

        在这些场景分析中评估人员分析了系统的架构风险、敏感点、权衡点，架构风险是指系统设计过程中潜在的、存在问题的架构决策所带来的隐患，其中L描述的是架构风险；敏感点是指为了实现某个特定质量属性，一个或多个构建具有的特性，其中H属于敏感点；权衡点是指影响多个质量属性的特性，且每个质量属性都属于敏感点，其中J属于权衡点。

        3、在测试阶段，结合银行的特殊性，经过项目干系人集体讨论后，确定了不同场景的优先级：系统安全性、可用性、可靠性最高，性能、可修改性其次，易用性优先级较低。在保障系统安全方面使用SSL数字证书的HTTPS访问协议，网络设备使用网闸、多层异构防墙、入侵防护系统，数据访问使用分级授权和数据加密存储。可用性方面使用VMware虚拟化平台加心跳技术，当服务器出现问题时候VMware虚拟机自动迁移到冗余主机。可靠性使用服务单独拆分、分层解耦设计，降低一个模块错误对全系统的影响，使用Spring拦截器对用户操作引起的错误进行统一容错处理。性能方面使用WEB中间件集群，针对高并发读写操作数据库使用Mysql读写分离。易用性采用界面设计的八分黄金法则，设计出多种风格让用户自由选择。

        4、报告阶段，经过架构的评估，将评估的过程和结果都汇总整理成文档。其中包括架构分析方法文档、不同场景及各自的优先级、质量效用树、风险点决策、非风险点决策、每次评估会议的记录。

        经过实践证明，实施软件架构评估正正确的识别项目风险点、敏感点、权衡点，提前预判并做好应对措施，做出合理的架构决策，从而提高项目开发的成功率和质量。经过10个月的开发，绩效考核平台已经顺利上线并稳定运行一年多，充分发挥了绩效激励、赛马式营销、政策指挥棒的作用， 目前已经在全行推广使用，得到了领导、员工、客户的一致好评。