系统架构师考试学习笔记第五篇——架构设计补充知识（26）论文写作
本章考点：
第26课时主要学习论文写作。根据考试大纲,论文满分为75分,为考试的压轴科目,俗话说“得论文者得天下”,其重要程度不言而喻。但是,“难者不会,会者不难”,考生应当正确面对、积极准备。
【导读小贴士】
系统架构设计师考试论文题目一般是四选一,范围覆盖系统建模、软件架构设计、系统设计、系统可靠性分析与设计、系统安全性和保密性设计等方面。只要考生积极提前准备、掌握论文写作框架、有针对性地训练,往往会水到渠成,顺利过关。
一、论文目的
我们研读考试大纲可以发现,论文最能体现“高级”两个字的真实含义。我们认为,考试设置论文的目的有四:一是考查考生是否具备足够的实践经验;二是考查考生是否具备足够的分析问题的能力;三是考查考生是否具备足够的解决问题的能力:四是考查考生是否具备足够的书面表达能力。简言之,丰富的实践经验、较强的分析问题能力、扎实的解决问题能力、流畅的书面表达能力,构成了系统架构设计师这一“高级工程师”的基本素养。
二、论文要求
我们试图从形式、内容两个方面来阐述论文的要求。
(1)形式方面的要求。首先,内容要丰满,即字数要够,其中摘要字数为290~320,正文字数为2200~2800;其次,卷面要整洁,字迹至少要容易辨认,最好不要有错别字,再次,无明显
的语法、文法纰漏,行文要清晰,要有逻辑。
(2)内容方面的要求。内容要求主要包含5个方面:一是实践性强,切忌夸大其词、自我标榜、过分吹嘘:二是契合题意,不跑题,切忌漏洞百出、离题万里;三是具备较高的深度和水平,切忌理论堆砌、泛泛而谈;四是要体现较强的综合分析能力;五是要能体现较好的书面表达能力,要求文字流畅、条理分明、逻辑清晰、表达严谨。
形式是表,也是数量的要求;内容是里,也是质量的要求。一篇合格的论文既要有正确的形式展现,又要有丰满内容的支撑,要求数量、质量两个方面均过关。
下述情况之一的论文,不能给予及格:
(1)虚构情节、论文中有较严重的不真实或者不可信的内容出现。
(2)没有项目开发的实际经验,通篇都是浅层次、纯理论的叙述。
(3)所讨论的内容与方法过于陈旧,或者项目的水准非常低下。
(4)内容不切题意,或者内容相对很空洞,基本上是泛泛而谈且没有体现参与人的深入体会的。
(5)正文与摘要的篇幅过于短小的。
(6)文理很不通顺、错别字很多、条理与思路不清晰、字迹过于潦草等情况相对严重的。
三、论文框架
1.摘要
顾名思义,摘要是论文的浓缩和精华,通过阅读摘要,读者就能大概知晓论文的内容。一般来说,摘要由下面3个部分组成:一是项目背景介绍,内容包括项目缘由、时间、项目名称、项目建设内容等,作者的工作角色和工作内容介绍;二是项目技术简介,结合题目要求简单介绍论文采用什么技术、方法、措施、手段等,解决了什么问题,是正文理论与实践的浓缩;三是项目效果简述。注意,摘要语言要精炼、概括,阐述要综合、浓缩,不宜详细展开,好的摘要是成功的一半。摘要不建议分段。
2.项目背景
项目背景这部分约400~500字。项目背景建议使用“5W2H”模式来展开,具体如下:
(1)Why:项目的由来、缘起、项目定位、项目目标等。
(2)When:何时,为体现技术先进性建议选近三年的项目,工期建议半年至一年。
(3)Where:何地,介绍项目发生地,不能出现实际的城市名,建议形式:某省谋市。
(4)Who:项目的甲乙双方,甲方名称需脱敏处理,乙方称“我司/我单位/我厂/我公司”。
(3)Whal:项目名称、项目的建设内容、作者的工作内容等。
(6) How much:项目规模、项目预算等。
(7) How:项目采用的技术、框架、方法、工具、措施等。
如果摘要写得好,就可以基于摘要的脉络,进一步细化展开阐述,这不失为一种好的实践方法。注意,项目背景选择非常重要,务必重点准备,不管考试出什么题目,项目背景都可以复用。关于项目选择,我们建议首选自己参与过、亲历过、深有体会的项目,其次选未参与但熟悉或能理解的项目,最后选不熟悉但通过阅读相关文档能理解的项目。简言之,越熟悉的项目,论文的材料就越充实,论述越能充分,行文时才能思如泉涌、一气呵成。
3.过渡部分
过渡这部分约100字,为了避免论文上下文语义断层,需要适当加入过渡语句,起承上启下的作用。在项目背景介绍完毕,考生需要识别出项目的关键需求、项目特征:、项目约束等主客观因素,提出满足这些因素需采取哪些理论、技术、措施、工具、手段,从而引出下文。
4. 理论部分
理论部分约400~600字。论文题干针对理论部分有明确的要求,:翻看历年的真题试卷,这一要求出现在第二小问比较常见。因此,作者需要单独并且完整地逐一应答,理论部分又称分论点,要注意紧扣题干,问什么答什么,无关内容不要赘述。理论部分决定了论文的水平高低,着重论述分论点的基本概念、基本原理、应用场景,适当简单举例。而基本概念、基本原理不必死记硬背,可以用自己的语言或自己的理解阐述,当然要注意阐述要严谨、科学、正确,否则有贻笑大方的可能。注意控制好字数,切忌洋洋洒洒上千字。
5.实践部分
实践部分约1000~1200字,是论文最重要的部分,也是最能体现作者水平高低的部分。结构上,建议与理论部分前后呼应、保持一致,做到紧扣分论点。为了便于读者阅读,建议提炼小标题,小标题需要好好斟酌,要能统领全段内容。针对每个分论点,建议采用“Why+How”来阐述,首先分析问题,然后解决问题。深入浅出,切忌纸上谈兵,实践部分不能写成千巴巴的理论堆砌。注意扬长避短,不能把实践部分写成产品介绍。
6.结尾
结尾约300-~400字。结尾部分首先需要呼应论点,然后可以介绍项目出现的小问题、项目效果、下一步计划,作者的收获等内容。注意首尾呼应,避免前后矛盾,另外在阐述问题时简单带过即可,切忌滔滔不绝。
四、论文写作常见问题
(1)摘要部分常见问题:
1)项目背景介绍缺失。
2)项目主要功能简介缺失
3)理论介绍缺失或不足。
4)摘要草草收尾。
5)字数不够,或写得太琐细。
6)摘要分段。
(2)项目背景部分常见问题:
1)只在摘要里介绍,而在正文里不介绍项目背景。
2)选择非软件项目,如硬件、网络、采购。
3)项目太陈旧。
4)项目采用的技术太陈旧。
5)虚构项目,明显不真实,违背常识。
6)“帽子”戴得太多。
7)项目与理论不匹配、不适合。
(3)过渡部分常见问题:
1)项目背景与理论之间缺少过渡句。
2)理论部分与实践部分缺少过渡句。
3)过渡生硬。
(4)理论部分常见问题:
1)篇幅太长,超过700字。
2)理论部分缺失。
3)未响应题干要求,或响应不足。
4)与实践部分揉在一起,未单独介绍。
5)基本概念、基本原理不清楚,介绍理论不严谨、不科学。
6)简单罗列,没有深入体会。
7)一个分论点没讲完,又讲到另一个。
8)与实践部分完全脱节。
(5)实践部分常见问题:
1)篇幅太短,阐述太单薄,浅尝辄止,泛泛而谈。
2)简单罗列,纯理论空谈。
3)自曝其短:知识点不懂、水平低下。
4)阐述框架未围绕论点/分论点,自创一套。
5)只阐述Why,不阐述How.
6)未从宏观/大局出发,过于强调微观细节。
7)使用不合适的、错误的技术手段去解决问题。
(6)结尾部分常见问题;
1)未呼应论点/分论点。
2)说起“问题”来滔滔不绝。
3)过于单薄,或过于元长。
4)首尾不一致,甚至前后矛盾。
五、备考建议
关于理论部分,建议与科目一、科目二协同准备,在理解的基础上记住要点,千万不要死记硬背。对于项目背景,建议考生选择自己熟悉的、亲历过的,技术与理论方面选择自己熟悉的、擅长的领域。建议先精写一篇论文练习,购买一点文具店里都有售的方格子作文纸(单页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,属于可靠性的有1,属于易用性的有E。在这些场景分析中评估人员分析了系统的架构风险、敏感点、权衡点。架构风险是指系统设计过程中潜在的、存在问题的架构决策所带来的隐患,其中L描述的是架构风险;敏感点是指为了实现某个特定质量属性,一个或多个构建具有的特性,其中H属于敏感点;权衡点是指影响多个质量属性的特性,且每个质量属性都属于敏感点,其中」属于权衡点。
(三)在测试阶段,结合银行的特殊性,经过项目干系人集体讨论后,确定了不同场景的优先级:系统安全性、可用性、可靠性最高,性能、可修改性其次,易用性优先级较低。在保障系统安全方面使用SSL数字证书的 HTTPS访问协议,网络设备使用网闸、多层异构防火墙、入侵防护系统,数据访问使用分级授权和数据加密存储。可用性方面使用 VMware 虚拟化平台加心跳技术,当服务器出现问题的时候 VMware 虚拟机自动迁移到冗余主机。可靠性方面使用服务单独拆分、分层解耦设计,降低一个模块错误对全系统的影响,使用 Spring 拦截器对用户操作引起的错误进行统一容错处理。性能方面采用Web中间件集群,针对高并发读写操作数据库使用 DB2 pureScale磁盘共享集群技术加 SSD 盘存储阵列。可修改方面系统对功能服务进行拆分,通过接口调用实现便捷修改。易用性方面采用界面设计的八大黄金法则,设计出多种风格让用户自由选择。
(四)报告阶段,经过架构的评估,将评估的过程和结果都汇总整理成文档。其中包括架构分析方法文档、不同场景及各自的优先级、质量效用树、风险点决策、非风险点决策、每次评估会议的记录。经过实践证明,实施软件架构评估能正确地识别项目风险点、敏感点、权衡点,提前预判并做好应对措施,做出合理的架构决策,从而提高项目开发的成功率和质量。经过7个月的开发,绩效考核平台顺利上线并稳定运行一年多,充分发挥了绩效激励、赛马式营销、政策指挥棒的作用,目前已在全行推广使用,得到了领导、员工、客户的一致好评。