[系统架构设计师]论文（二十三）

[系统架构设计师]论文（二十三）

一.论软件系统架构评估

1.架构所关注的质量属性主要有：性能，可用性，安全性，可修改性

1）性能。性能是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。

2）可用性。可用性是指系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在系统出现故障能够恢复正常的速度来表示。

3）安全性。安全性是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可以划分为机密性，完整性，不可否认性及可控性等特性。

4）可修改性。可修改性是指能够快速地以较高的性能价格比对系统变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。

2.架构评估方法主要有SAAM和ATAM中选择

1）SAAM评估方法：目的是验证基本的体系结构假设和原则，评估体系固有的风险。SAAM指导对体系结构的检查，使其主要关注潜在的问题点，如需求冲突。SAAM不仅能够评估体系结构对于特定系统需求的使用能力，也能被用来比较不同的体系结构。这种评估方法的评估参与者有风险承担者，记录人员，软件体系结构设计师。SAAM分析评估体系结构的过程包括6个步骤，即形成场景，描述体系结构，场景的分类和优先级确定，间接场景的单个评估，场景相互作用的评估，总体评估。

2）ATAM评估方法：即架构权衡分析方法的评估目的是依据系统质量属性和商业需求评估设计决策的结果。ATAM希望揭示出构架满足特定质量目标的情况，使我们更清楚地认识到质量目标之间的联系，即如何权衡多个质量目标。

评估参与者有：

1.评估小组。该小组使所评估架构项目外部的小组，通常由3~5个人组成。ATAM小组的每个成员都要扮演大量的特定角色。他们可能是开发组织内部的，也可能是外部的。

2.项目决策者，对开发项目具有发言权，并有权要求进行某些改变，他们包括项目管理人员，重要的客户代表，架构设计师等。

3.架构涉众。包括关键模块开发人员，测试人员，用户等

现代的ATAM评估过程包括9个步骤：描述ATAM方法，描述商业动机，描述体系结构，确定体系结构方法，生成质量属性效用树，分析体系结构方法，讨论和分级场景，描述评估结果

二.论软件架构的复用

软件架构复用的基本过程如下:

（1）构建/获取可复用的软件资产是复用前提。首先需要构造恰当的，可复用的资产，并且这些资产必须是可靠的，可被广泛使用的，易于理解和修改的。

（2）管理可复用资产。用构件库对可复用的构件进行存储与管理。构件库应提供的主要功能包括构件的存储，管理，检索，以及库的浏览与维护等，以及支持使用者有效地，准确地发现所需的可复用构件。构件库中的构件来源有：

1）从现有构件库中获得符合要求的构件，直接使用或作适应性修改，得到可复用的构件。

2）通过遗留工程，将具有潜在复用价值的构件提取出来，得到可复用的构件。

3）从市场上购买现成的商业构件

4）开发符合新的符合新的构件

构件分类与检索的方法有：关键字分类法，刻面分类法，超文本方法

（3）使用可复用资产。通过获取需求，检索复用资产库，获取可复用资产，并定制这些可复用的资产进行修改，扩展，配置等，最后将它们组装与集成，形成最终系统。

三.论分布式存储系统架构设计

分布式存储技术主要包括4类：

（1）集群存储技术

集群存储系统是指架构在一个可扩充服务器集群中的文件系统，用户不需要考虑文件存储在集群中的什么位置，仅仅需要统一访问界面就可以访问文件资源。当负载增加时，只需要在服务器集群中增加新的服务器就可以提高文件系统的性能。集群存储系统能够保留传统文件存储系统的语义，增加了集群存储系统必须的机制，可以向用户提供高可靠性，高性能，可扩充的文件存储服务。

（2）分布式文件系统

分布式文件系统是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。分布式文件系统的设计基于客户机/服务器模式。一个典型的网络可能包括多个供多用户访问的服务器。另外，对等特性允许一些系统扮演客户机和服务器的双重角色。分布式文件系统以透明方式链接文件服务器和共享文件夹，然后将其映射到单个层次结构，以便可以从一个位置对其进行访问，而实际上数据却分布在不同的位置。用户不必再转至网络上的多个位置以查找所需的信息。

（3）网络存储技术

网络存储系统就是将"存储"和"网络"结合起来，通过网络连接各存储设备，实现存储设备之间，存储设备和服务器之间的数据在网络上的高性能传输。为了充分利用资源，减少投资，存储作为构成计算机系统的主要架构之一，就不再仅仅担负附加设备的角色，逐步称为独立的系统。利用网络将此独立的系统和传统的用户设备连接，使其以高速，稳定的数据存储单元存在。用户可以方便地使用浏览器等客户端进行访问和管理。

（4）P2P网络存储技术

P2P网络存储技术的应用使得内容不是存在几个主要的服务器上，而是存在所有用户的个人电脑上。这就为网络存储提供了可能性，可以将网络中的剩余存储空间利用起来，实现网络存储。人们对存储容量的需求是无止境的，提高存储能力的方法有更换能力更强的存储器，或把多个存储器用某种方式连接在一起，实现网络并行存储。相对于现有的网络存储系统而言，应用P2P技术将会有更大的优势。P2P技术的主体就是网络中的Peer，也就是各个客户机，数量是很大的，这些客户机的空闲存储空间是很多的，把这些空间利用起来实现网络存储。

常见冗余技术：数据备份，数据分割，门限方案，纠错编码和纠删编码等

冗余是提高分布式存储系统可靠性的主要方法，冗余的存储结构可以保证部分服务器失效时，数据服务仍可正常访问。

四.论微服务架构及其应用

微服务优势：

（1）通过分解巨大单体式应用为多个服务方法解决了复杂性问题。它把庞大的单一模块应用分解为一系列的服务，同时保持总体功能不变，但整体并发却得到极大提升

（2）让每个服务能够独立开发，开发者能够自由选择可行的技术，提供API服务

（3）微服务架构模式是每个微服务独立的部署。开发者不再需要协调其他服务部署对本服务的影响。这种改变可以加快部署速度。

（4）微服务使得每个服务独立扩展。开发者可以根据每个服务的规模来部署满足需求的规模。甚至可以使用更适合于服务资源需求的硬件。

微服务带来的挑战：

（1）并非所有的系统都能转成微服务

（2）部署较以往架构更加复杂：系统内由众多微服务搭建，每个微服务需要单独部署，从而增加部署的复杂度，容器技术能够解决这一问题。

（3）性能问题：由于微服务注重独立性，互相通信时只能通过标准接口，可能产生延迟或调用出错

（4）数据一致性问题：作为分布式部署的微服务，在保持数据一致性方面需要比传统架构更加困难

五.论软件架构风格

常见的，经典的架构风格

1）数据流风格：包括批处理体系结构风格、管道-过滤器风格

2）管道-过滤器风格：包括主程序/子程序风格、面向对象风格、层次型风格（C/S 架构、 B/S 架构）

3）以数据为中心的风格：包括仓库体系结构风格、黑板体系结构风格

4）虚拟机风格：包括解释器风格、规则系统风格

5）独立软件架构风格：进程通信风格、事件系统风格

6）C2风格：C2 风格也被认为是层次风格的一种

现代的体系结构风格：微服务，SOA

六.论企业应用系统的层次式架构风格

1）表现层。表现层主要负责接收用户的请求，对用户的输入、输出进行检查与控制，处理客户端的一些动作，包括控制页面跳转等，并向用户呈现最终的结果信息。可以使用 MVC 模式来设计表现层

2）中间层。中间层负责实现系统的业务功能，主要包括业务逻辑层组件、业务逻辑层工作流、业务逻辑层实体和业务逻

辑层框架四个方面。业务逻辑层组件分为接口和实现类两个部分，接口用于定义业务逻辑组件，定义业务逻辑组件必须实

现的方法。通常按模块来设计业务逻辑组件，每个模块设计为一个业务逻辑组件，并且每个业务逻辑组件以多个 DAO 组

件作为基础，从而实现对外提供系统的业务逻辑服务。业务逻辑层工作流能够实现在多个参与者之间按照某种预定义的规

则传递文档、信息或任务的过程自动进行，从而实现某个预期的业务目标，或者促进此目标的实现。业务逻辑层实体提供

对业务数据及相关功能的状态编程访问，业务逻辑层实体数据可以使用具有复杂架构的数据来构建，这种数据通常来自数

据库中的多个相关表。业务逻辑层实体数据可以作为业务过程的部分 I/O 参数传递，业务逻辑层的实体是可序列化的，以

保持它们的当前状态。业务逻辑层是实现系统功能的核心组件，采用容器的形式，便于系统功能的开发、代码重用和管理

3）持久层。持久层主要负责数据的持久化存储，主要负责将业务数据存储在文件、数据库等持久化存储介质中。持久层

可以使用在线访问、Data Access Object、Data Transfer Object、离线 数据模式、对象/关系映射（Object/Relation Mapping）5 种数据访问方式

七.论面向服务的架构设计

（1）UDDI 协议：统一描述、发现和集成协议。包含了服务描述与发现的标准规范，它使得商业

实体能够彼此发现；定义它们怎样在 Internet 上互相作用，并在一个全球的注册体系架构中共享信息。

（2）Web 服务描述语言（Web Services Description Language，WSDL）：是一个用来描述 Web

服务和说明如何与 Web 服务通信的 XML 语言。

（3）SOAP 协议：SOAP 是在分散或分布式的环境中交换信息的简单的协议，是一个基于

XML 的协议。

（4）REST 规范：为了让不同的软件或者应用程序在任何网络环境下都可以进行信息的互相

传递。微服务对外就是以 REST API 的形式暴露给调用者。RESTful 即 REST 形式的，是对遵循

REST 设计思想同时满足设计约束的一类架构设计或应用程序的统称，这一类都可称为 RESTful，

可以理解为资源表述性状态转移。

（5）通信协议标准：SOA 服务用消息进行通信，该消息通常使用 XML Schema 来定义（也称

作 XML Schema Definition，XSD）。

SOA 的设计原则主要有：

（1）无状态。以避免服务请求者依赖于服务提供者的状态。

（2）单一实例。以高内聚的实现方法，来避免功能冗余。

（3）明确定义的接口。服务的接口由 WSDL 定义，用于指明服务的公共接口与其内部专用

实现之间的界线。

（4）自包含和模块化。服务封装了那些在业务上稳定、重复出现的活动和组件，实现服务的

功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。

（5）粗粒度。服务数量不应该太大，依靠消息交互而不是远程过程调用（RPC），通常消息量

较大，但是服务之间的交互频度较低。

（6）服务之间的松耦合性。服务使用者看到的是服务的接口，其位置、实现技术和当前状态

等对使用者是不可见的，服务私有数据对服务使用者是不可见的。

（7）重用能力。服务应该是可以复用的。

（8）互操作性、兼容和策略声明。为了确保服务规约的全面和明确，利用策略来定义可配置

的互操作语义，来描述特定服务的期望、控制其行为。利用策略声明确保服务期望和语义兼容性方

面的完整和明确。

八.论基于架构的软件设计方法及应用

采用 ABSD 方法进行软件开发时，需要经历架构需求、架构设计、架构文档化、架构复审、

架构实现和架构演化 6 个阶段：

（1）架构需求。架构需求阶段需要明确用户对目标软件系统在功能、行为、性能、设计约束

等方面的期望。其主要活动包括需求获取、标识构件和架构需求评审。需求获取活动需要定义开发

人员必须实现的软件功能，使得用户能够完成他们的任务，从而满足功能需求。与此同时，还要获

得软件质量属性，满足一些非功能性需求。标识构件活动首先需要获得系统的基本结构，然后对基

本结构进行分组，最后将基本结构进行打包成构件。架构需求评审活动组织一个由系统涉众（用户、

系统分析师、架构师、设计实现人员等）组成的小组，对架构需求及相关构件进行审查。审查的主

要内容包括所获取的需求是否真实反映了用户需求，构件合并是否合理等。

（2）架构设计。这个阶段是一个迭代过程，利用架构需求生成并调整架构决策。主要活动包括提

出架构模型、将已标识的构件映射到架构中、分析构件之间的相互作用、产生系统架构和架构设计评审。

（3）架构文档化。主要活动是对架构设计进行分析与整理，生成架构规格说明书和测试架构

需求的质量设计说明书。

（4）架构复审。在一个主版本的软件架构分析之后，需要安排一次由外部人员（客户代表和领域

专家）参加的架构复审。架构复审需要评价架构是否能够满足需求，质量属性需求是否在架构中得以体

现，层次是否清晰，构件划分是否合理等。从而标识潜在的风险，及早发现架构设计中的缺陷和错误。

（5）架构实现。主要是对架构进行实现的过程，主要活动包括架构分析与设计、构件实现、

构件组装和系统测试。

（6）架构演化。这个阶段主要解决用户在系统开发过程中发生的需求变更问题。主要活动包

括架构演化计划、构件变动、更新构件的相互作用、构件的组装与测试和技术评审。

在软件开发的过程中可能遇到的问题主要包括：在架构需求获取过程中如何对捕获的架构需求进行

筛选和优先级排序；在架构复审过程中如何解决评审人员意见不一致的问题；在架构实现过程中如何根

据项目组实际情况选择开发语言与开发平台；在架构演化过程中如何筛选并处理用户的需求变更等。

九.论文框架

1．摘要

顾名思义，摘要是论文的浓缩和精华，通过阅读摘要，读者就能大概知晓论文的内容。一般来

说，摘要由下面 3 个部分组成：一是项目背景介绍，内容包括项目缘由、时间、项目名称、项目建

设内容等，作者的工作角色和工作内容介绍；二是项目技术简介，结合题目要求简单介绍论文采用

什么技术、方法、措施、手段等，解决了什么问题，是正文理论与实践的浓缩；三是项目效果简述。

注意，摘要语言要精炼、概括，阐述要综合、浓缩，不宜详细展开，好的摘要是成功的一半。摘要

不建议分段。

2．项目背景

项目背景这部分约 400～500 字。项目背景建议使用“5W2H”模式来展开，具体如下：

（1）Why：项目的由来、缘起、项目定位、项目目标等。

（2）When：何时，为体现技术先进性建议选近三年的项目，工期建议半年至一年。

（3）Where：何地，介绍项目发生地，不能出现实际的城市名，建议形式：某省/某市。

（4）Who：项目的甲乙双方，甲方名称需脱敏处理，乙方称“我司/我单位/我厂/我公司”。

（5）What：项目名称、项目的建设内容、作者的工作内容等。

（6）How much：项目规模、项目预算等。

（7）How：项目采用的技术、框架、方法、工具、措施等。

如果摘要写得好，就可以基于摘要的脉络，进一步细化展开阐述，这不失为一种好的实践方法。

注意，项目背景选择非常重要，务必重点准备，不管考试出什么题目，项目背景都可以复用。关于

项目选择，我们建议首选自己参与过、亲历过、深有体会的项目，其次选未参与但熟悉或能理解的

项目，最后选不熟悉但通过阅读相关文档能理解的项目。简言之，越熟悉的项目，论文的材料就越

充实，论述越能充分，行文时才能思如泉涌、一气呵成。

3．过渡部分

过渡这部分约 100 字，为了避免论文上下文语义断层，需要适当加入过渡语句，起承上启下的

作用。在项目背景介绍完毕，考生需要识别出项目的关键需求、项目特征、项目约束等主客观因素，

提出满足这些因素需采取哪些理论、技术、措施、工具、手段，从而引出下文。

4．理论部分

理论部分约 400～600 字。论文题干针对理论部分有明确的要求，翻看历年的真题试卷，这一

要求出现在第二小问比较常见。因此，作者需要单独并且完整地逐一应答，理论部分又称分论点，

要注意紧扣题干，问什么答什么，无关内容不要赘述。理论部分决定了论文的水平高低，着重论述

分论点的基本概念、基本原理、应用场景，适当简单举例。而基本概念、基本原理不必死记硬背，

可以用自己的语言或自己的理解阐述，当然要注意阐述要严谨、科学、正确，否则有贻笑大方的可

能。注意控制好字数，切忌洋洋洒洒上千字。

5．实践部分

实践部分约 1000～1200 字，是论文最重要的部分，也是最能体现作者水平高低的部分。结构

上，建议与理论部分前后呼应、保持一致，做到紧扣分论点。为了便于读者阅读，建议提炼小标题，

小标题需要好好斟酌，要能统领全段内容。针对每个分论点，建议采用“Why+How”来阐述，首

先分析问题，然后解决问题。深入浅出，切忌纸上谈兵，实践部分不能写成干巴巴的理论堆砌。注

意扬长避短，不能把实践部分写成产品介绍。

6．结尾

结尾约 300～400 字。结尾部分首先需要呼应论点，然后可以介绍项目出现的小问题、项目效

果、下一步计划、作者的收获等内容。注意首尾呼应，避免前后矛盾，另外在阐述问题时简单带

过即可，切忌滔滔不绝。

十.范文赏析

论软件架构评估

摘要

我所在单位是国内某商业银行，2017 年 1 月我行决定开发全新一代绩效考核平台系统，我担

任本次系统开发的架构师，主要负责整个系统的架构设计工作。该系统是既要满足内控管理的绩效

考核，又要满足银行粉丝客户参与营销的综合性绩效平台，是银行应对互联网金融变革和笃行普惠

金融的重要系统。本文结合我的实践，以绩效考核平台系统建设为例，论述软件系统架构评估。首

先分析了软件架构评估所普遍关注的质量属性并阐述其具体含义，然后详细说明本次项目软件架构

评估采用的 ATAM 评估方法、实施过程，评估小组经过对系统中的风险点、敏感点、权衡点进行

分析后生成质量效用树。通过 ATAM 架构评估保证了绩效考核平台系统的顺利完成，目前系统

已经稳定运行一年多，得到了领导、员工、客户的一致好评。

正文

我所在的单位是长三角地区某城市商业银行，机构覆盖全国多个省、直辖市。目前银行业正面

临互联网金融浪潮的冲击，银行需要积极转型、自我变革，不仅要服务好优质客户，还要抓住普通

大众客户，发展新零售拓展小微企业客户业务成为当下银行的战略要点，绩效考核将成为银行战略

转型的有效指挥棒。正是在这一背景下我行提出建设全新一代绩效考核平台，既对传统的绩效考核

做出调整，又结合互联网化的“粉丝及员工”理念，搭建多维度、多渠道、多群体的绩效考核平台。

银行绩效考核涵盖传统存贷款考核、产品营销考核、专项考核几大方面，对银行员工管辖的存

贷款计价模型计算员工创造利润、产品营销结果、专项产品达标情况等可量化的指标来考核员工，

对客户为银行推销的产品进行量化统计并给予奖励，银行总部通过不同的计价系数和组合策略引导

全体员工向政策目标迈进，将绩效考核形成指挥棒。

本绩效考核平台系统采用 J2EE 技术开发的 B/S 架构系统，使用 SOA 架构设计方法，数据库

使用 IBM DB2 10.5，Redis 内存数据库，服务器操作系统采用 Redhat 7.2 等。

软件质量特性是软件架构设计关注的一个重点，在软件架构评估中的质量属性包含性能、可用

性、安全性、可修改性、可靠性、易用性、可测试性等，其中前 4 个质量属性是质量效应树的重要

组成部分。具体含义如下。

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

事件的个数。

（2）可用性是指系统能正常运行的时间比。

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

务能力。

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

（5）可靠性是指软件系统在应用或错误面前、在意外或错误使用情况下维持系统的功能特性

的基本能力。

（6）易用性是衡量一个用户使用软件产品完成指定任务的难易程度。

常用的架构评估方法有基于问卷调查的评估方法、基于度量的评估方法、基于场景的评估方法。

基于问卷调查的方法具有主观性，不太适合本项目；基于度量的方法虽然评价比较客观，但需要评

价者对系统架构有精确的了解，所以也不太适合本项目；而基于场景的方法要求评估者对系统较为

了解，评价比较客观，故本项目采用了基于场景的评估方法。基于场景的评估方法又分为架构分析

法（SAAM）、架构权衡分析法（ATAM）和成本效益分析法（CBAM）。本项目根据不同质量属性

使用了 ATAM 作为系统架构评估的方法。

在进行架构评估时，按照需要确定了评估参与者，评估小组由总行业务人员、支行行长代表、

主办会计代表、客户经理和柜员代表、客户代表等；项目决策组成员包含总行行长、首席信息官、

业务部主管、系统架构师、项目经理、员工代表等。架构涉众还包含项目开发人员、测试人员、运

维人员等。架构评估经历了描述和介绍阶段、调查和分析阶段、测试阶段、报告阶段。下面我分别

对这四个阶段进行介绍：

（一）描述和介绍阶段，由于参与评估的人员有一部分对 ATAM 评估不了解，我首先介绍了

ATAM 架构评估的方法和目的。项目决策组组长、业务主管等人介绍了绩效考核平台的业务动机。

最后我作为系统架构设计师描述了整个系统采用 SOA 架构实现，如何将系统划分为若干独立子系

统，各个子系统包含的功能及细节，如何与银行内的其他系统协作，怎么进行安全规划。

（二）在调查和分析阶段，结合场景不同角色的需求方都基于各自立场提出了相关需求，需求

及质量场景如下：

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

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 和 C，属于可修改性的有 K，属于可靠性的有 I，属于易用性的有 E。在这些场景分析

中评估人员分析了系统的架构风险、敏感点、权衡点。架构风险是指系统设计过程中潜在的、存在

问题的架构决策所带来的隐患，其中 L 描述的是架构风险；敏感点是指为了实现某个特定质量属

性，一个或多个构建具有的特性，其中 H 属于敏感点；权衡点是指影响多个质量属性的特性，且

每个质量属性都属于敏感点，其中 J 属于权衡点。

（三）在测试阶段，结合银行的特殊性，经过项目干系人集体讨论后，确定了不同场景的优先

级：系统安全性、可用性、可靠性最高，性能、可修改性其次，易用性优先级较低。在保障系统安

全方面使用 SSL 数字证书的 HTTPS 访问协议，网络设备使用网闸、多层异构防火墙、入侵防护系

统，数据访问使用分级授权和数据加密存储。可用性方面使用 VMware 虚拟化平台加心跳技术，

当服务器出现问题的时候 VMware 虚拟机自动迁移到冗余主机。可靠性方面使用服务单独拆分、

分层解耦设计，降低一个模块错误对全系统的影响，使用 Spring 拦截器对用户操作引起的错误进

行统一容错处理。性能方面采用 Web 中间件集群，针对高并发读写操作数据库使用 DB2 pureScale

磁盘共享集群技术加 SSD 盘存储阵列。可修改方面系统对功能服务进行拆分，通过接口调用实现

便捷修改。易用性方面采用界面设计的八大黄金法则，设计出多种风格让用户自由选择。

（四）报告阶段，经过架构的评估，将评估的过程和结果都汇总整理成文档。其中包括架构分

析方法文档、不同场景及各自的优先级、质量效用树、风险点决策、非风险点决策、每次评估会议

的记录。经过实践证明，实施软件架构评估能正确地识别项目风险点、敏感点、权衡点，提前预判

并做好应对措施，做出合理的架构决策，从而提高项目开发的成功率和质量。经过 7 个月的开发，

绩效考核平台顺利上线并稳定运行一年多，充分发挥了绩效激励、赛马式营销、政策指挥棒的作用，

目前已在全行推广使用，得到了领导、员工、客户的一致好评。