26-论文写作方法（第26小时）

软考-系统架构设计师 | 第5篇 架构设计补充知识 论文题：下午 75 分钟，1 题必答+2 选 1，总分 75 分（占下午一半分值） 论文不通过 = 整科不通过 “得论文者得天下” —— 投入 30% 复习时间！

0. 论文目的与要求

0.1 论文目的

系统架构设计师考试论文最能体现"高级"两个字的真实含义。论文考查考生的四大能力：

1. 实践经验（是否具备足够的项目经验）
2. 分析问题能力
3. 解决问题能力
4. 书面表达能力

简言之：丰富的实践经验 + 较强的分析能力 + 扎实的解决问题能力 + 流畅的书面表达 = 系统架构设计师基本素养。

0.2 论文要求（形式）

0.3 论文要求（内容 5 方面）

1. 实践性强 —— 切忌夸大其词、过分吹嘘
2. 契合题意 —— 不跑题，不漏洞百出
3. 具备较高的深度和水平 —— 切忌理论堆砌、泛泛而谈
4. 较强的综合分析能力
5. 较好的书面表达能力 —— 文字流畅、条理分明、逻辑清晰、表达严谨

0.4 不可及格的情形

出现以下任一情况，论文不予及格：

1. 虚构情节，论文中有较严重的不真实/不可信内容
2. 没有项目开发的实际经验，通篇浅层次纯理论叙述
3. 讨论内容/方法过于陈旧，或项目水准非常低下
4. 内容不切题意，或内容相对空洞，泛泛而谈无深入体会
5. 正文与摘要的篇幅过于短小
6. 文理不通、错别字多、条理不清、字迹过于潦草

1. 论文框架

1.1 摘要（290~320 字）

摘要是论文的浓缩和精华。不分段。

摘要三部分结构：

1. 项目背景介绍（包括项目缘由、时间、项目名称、项目建设内容；作者的工作角色和工作内容）
2. 项目技术简介（结合题目要求，介绍采用什么技术、方法、措施、手段等，解决了什么问题）
3. 项目效果简述

摘要语言要精炼、概括，阐述要综合、浓缩，不宜详细展开。

1.2 项目背景（约 400~500 字）

“5W2H” 模式展开：

项目选择优先级：

1. 首选：自己参与过、亲历过、深有体会的项目
2. 次选：未参与但熟悉或能理解的项目
3. 末选：不熟悉但通过阅读相关文档能理解的项目

项目背景务必重点准备，不管考什么题目，项目背景都可复用。

1.3 过渡部分（约 100 字）

• 项目背景介绍完毕 → 识别关键需求、项目特征、项目约束
• 提出满足这些因素需采取的理论/技术/措施/工具/手段
• 承上启下，避免上下文语义断层

1.4 理论部分（约 400~600 字）

• 论文题干对理论部分有明确要求（第二小问比较常见）
• 单独、完整地逐一应答 → 分论点
• 紧扣题干，问什么答什么，无关内容不要赘述
• 阐述基本概念、基本原理、应用场景，适当简单举例
• 用自己的语言或理解阐述（不必死记硬背），但要严谨、科学、正确
• 字数控制在 600 字以内，切忌洋洋洒洒上千字

1.5 实践部分（约 1000~1200 字，论文最重要部分）

• 结构上与理论部分前后呼应、保持一致，紧扣分论点
• 提炼小标题（小标题需仔细斟酌，能统领全段内容）
• 针对每个分论点，采用 “Why + How” 模式：
  1. 首先分析问题（Why）
  2. 然后解决问题（How）
• 深入浅出，切忌纸上谈兵
• 注意扬长避短，不能写成产品介绍

1.6 结尾（约 300~400 字）

• 呼应论点
• 可介绍：项目出现的小问题、项目效果、下一步计划、作者的收获
• 首尾呼应，避免前后矛盾
• 阐述问题简单带过，切忌滔滔不绝

2. 论文写作常见问题

2.1 摘要部分

2.2 项目背景部分

2.3 过渡部分

2.4 理论部分

2.5 实践部分

2.6 结尾部分

3. 备考建议

3.1 准备策略

1. 理论部分：与科目一、科目二协同准备，在理解的基础上记住要点
2. 项目背景：选自己熟悉的、亲历过的，技术与理论方面选自己擅长的
3. 精写一篇练习：购买方格子作文纸（单页 400 字），用硬笔练习
4. 修改流程：自己大声朗读一遍 → 修改 → 请家人读一读 → 修改 → 有条件请专业老师批改
5. 真题实战：精练一篇后，把近三年历年真题都写一遍

3.2 时间分配

• 投入 30% 复习时间给论文（75 分占整科 50%）
• 准备 4-5 个真实项目背景（不同行业）
• 准备 8-10 个常见论文题目的提纲
• 限时模拟 3-5 次（75 分钟写完）

3.3 论文题目范围（4 选 1）

• 系统建模
• 软件架构设计
• 系统设计
• 系统可靠性分析与设计
• 系统安全性和保密性设计
• 关注"四高"主题：层次式 / SOA / 大数据 / 云原生（参见第4篇 README）

4. 范文赏析 —— 论软件架构评估

4.1 摘要

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

4.2 正文要点（节选）

项目背景：

• 长三角地区某城市商业银行，机构覆盖全国多个省、直辖市
• 银行面临互联网金融浪潮的冲击 → 战略转型 → 绩效考核成为指挥棒
• 项目目标：搭建多维度、多渠道、多群体的绩效考核平台

技术栈：

• J2EE 技术 / B/S 架构
• SOA 架构设计方法
• IBM DB2 10.5
• Redis 内存数据库
• Redhat 7.2

软件质量属性 6 项：

1. 性能 —— 系统响应能力
2. 可用性 —— 系统能正常运行的时间比
3. 安全性 —— 阻止非授权用户/拒绝服务能力
4. 可修改性 —— 快速、以较高性价比对系统变更的能力
5. 可靠性 —— 应用或错误面前维持功能的基本能力
6. 易用性 —— 衡量用户完成指定任务的难易程度

架构评估方法选择：

• 问卷调查法 → 主观性强，不适合
• 度量法 → 需精确了解架构，不适合
• 场景法 → 评价客观，本项目采用
• 场景法细分：SAAM / ATAM / CBAM → 本项目采用 ATAM

ATAM 评估 4 阶段：

1. 描述和介绍阶段 —— 介绍 ATAM 方法、业务动机、SOA 架构、子系统划分
2. 调查和分析阶段 —— 收集质量场景
3. 测试阶段 —— 确定场景优先级，针对性方案设计
4. 报告阶段 —— 整理文档（方法/场景/优先级/质量效用树/风险点决策）

质量效用树：

• 性能 → A
• 可用性 → F、G
• 安全性 → B、C
• 可修改性 → K
• 可靠性 → I
• 易用性 → E

架构决策（针对质量属性）：

• 安全性：SSL 数字证书 / HTTPS / 网闸 / 多层异构防火墙 / 入侵防护 / 分级授权 / 数据加密
• 可用性：VMware 虚拟化 + 心跳技术
• 可靠性：服务单独拆分 / 分层解耦 / Spring 拦截器统一容错
• 性能：Web 中间件集群 / DB2 pureScale 磁盘共享集群 + SSD
• 可修改性：服务拆分 + 接口调用
• 易用性：界面设计八大黄金法则

项目结果：

• 7 个月开发 → 顺利上线 → 稳定运行一年多
• 已在全行推广使用，得到领导、员工、客户一致好评

5. 关键概念速查

6. 高频考点

1. 论文字数：摘要 290320 / 正文 22002800
2. 5W2H 项目背景：Why/When/Where/Who/What/How much/How
3. 项目选择优先级：参与过 → 熟悉 → 文档能理解
4. 理论部分控制：400~600 字，紧扣题干分论点
5. 实践部分模式：Why + How，每个分论点对应小标题
6. 不可及格 6 种情形：虚构/无经验/方法陈旧/不切题/篇幅短/文理差
7. 质量属性 6 项：性能/可用性/安全性/可修改性/可靠性/易用性
8. 架构评估三方法：问卷调查（主观）/度量（精确要求）/场景（客观，本项目用）
9. 场景法细分：SAAM / ATAM / CBAM
10. ATAM 4 阶段：描述介绍 → 调查分析 → 测试 → 报告
11. 架构决策三概念：风险点 / 敏感点 / 权衡点
12. 论文投入：30% 复习时间（占整科 50% 分值）