混过系统分析师——之论文无敌
前言
本人参加了三年系统分析师的考试(每年2次),除了第一次考试论文42分外,其它几次考试论文部分都通过,但也都只是刚够及格多一点,直到今年上半年通过这项考试,以致我后来都不担心论文。我完全是倚靠个人工作经验去对付这项考试的,尤其是论文,可以说是没有任何准备,完全靠自己的感觉写。
本文适合那些同我一样在工作的同志,不适合在校学生,不适合以优秀为目标的同志,仅为只为混个及格的同志们提供一些经过实践考验的经验。
原则
不要以为这是高中作文,不要以写出一篇好的论文为目标,这不是文档工程师的考试。关键是表达自己是有工作经验的,且这些经验足够资深,这么个意思。对于没有工作经验的人,这就是一件非常有难度的技术活,就像是在伪造自己的工作经验或简历一样,在那么多页纸的文字中,总要露出马脚的。所以,你只要把你工作中的内容给表现出来就可以了,让人一看就知道你是参加工作多年的,对于真正从事多年工作的人来说,这点并不难,除非你文字表达能力超级差。
我建议在文章中重点论述自己在工作中总结出的观点,而不是照搬照抄书本,这并不是要求你标新立异,而是将你切实的体会写下来,实际的而与书本不同的东西。
准备
不要去准备一篇现成的论文来背,无论是自己预先写好的,还是请别人代写的,不要寄期望于那么一篇论文,你的想法是不可能实现的,而且是幼稚的,除非你预先知道考题。
你需要准备的是1-2个你最熟悉的项目,最好你就是项目的负责人或主要成员,在考试前几天,在脑子里默默地回忆项目的全过程,从需求分析到后期维护,将项目的全过程在心里梳理一边,或几边,默默地组织一些语言,不要管实际的题目是什么,那是你不可能知道的事情。
论文有四个题目让你选,软件工程是不可能缺少的,总是有可以对上或沾边的题目,否则你准备了2个项目的全过程都没有能沾边,那么你立即交白卷走人,下次再来。
我自己考了那么多次,总共就用了2个项目案例,是我经历的最大的两个任务,一个是关于异构数据交换的,前几年一直在做这个,开发了很多版本,也在很多项目中应用;用它写了一次关于需求分析的论文,主要是说明需求分析可以明确设计目标和缩减开发成本,在需求分析阶段,我砍掉了一些原先设计的功能,反而使整个系统和我的软件都获得了解放,变得更好;还用它写过自动控制中的人机交互技术,这里我提出了模块与界面分离的技术,界面成为了程序的外壳,更新或重写界面变得与功能独立,非常快捷,这样就缩短与客户反复的时间,以及界面修改要求不会影响到模块,并提高了模块的复用率等等。
第二个是关于数据库方面的,这是我现在的主要工作内容,用它写过软件的可靠性设计方法,里面主要描述了如何让数据库服务器不死的各种方法,和大型软件的异常处理与异常中的运行机制;还写过分布式数据库设计,虽然我做的数据库不是分布式的,但还是将它假设修改为分布式的来写,在论文中描述了一种我脑海中的分布式数据库;还有软件的可行性分析,主要分析了在围绕新产品(数据库)设计中的决策过程,其实是一种对比论证的简单方法,这是最后一次考试的论文。
或许你扎眼看上去和自己的项目八竿子打不着,但总可以找到合适的切题点。
如果你的文字表达能力比较弱,或者写字很满或很难看的话,建议你先在脑子里准备好项目后,任意取以往的一次真题来试试,注意时间。我个人认为,在高速书写过程中保持字体端正才是最重要的,绝对是高速环境。
草稿
建议不打草稿,或只在心理打草稿,因为如果你是第一次参加这项考试,那么估计你的时间会不够,如果你用半个小时还没有正式开始写,那么你的时间肯定不够,或者字数偏少。还是那句话,不要把它当作是作文,不要把重点放在如何写好一篇文章上,你的文章可以写的比较马虎或粗糙,其实阅卷人不看你这些。
我总是选定题目后稍加思索便开始直接写,五分钟内肯定动笔,动笔的时候未必把整个论文都想的很明白,甚至不知道需要有那些观点和例子,文章的结构也没有设计好,边写边想,边写边调整。可能我属于特例,我自认为写东西的能力还是比较出众的,从来都不喜欢打草稿,即便是在纸上写。
但你要认认真真地去写份草稿,那肯定是来不及的,有的甚至喜欢在草稿纸上写完后再誊抄到试卷上,那只会使时间更紧张,没有那个必要那么重视文章的内容本身。你经历过一次就会知道,看似时间很充裕,其实根本就不够,我参加了那么多次考试,后来几乎都是我第一个交卷的,但也没有提前30分钟,写论文的整个过程,还是以“赶”为主,你根本就无法充分构思,建议你边写边构思,边写边调整。
建议你在10分钟内想好你的中心论点和文章大体结构,其他的如具体项目的描述、举那些例子、细节层次结构,有个大概,模模糊糊就可以动笔了。
摘要
放到最后来写,摘要应放到和正文同等重要的地位,保证最后有30分钟左右的时间可以来构思和完成摘要。因为摘要的篇幅很小,所以需要在脑子里基本组织好后,一气呵成,应控制字数基本将摘要的格子全部用完,摘要不能过少。
如果写完后发现摘要较少,如还空2-3行,可以增加关键字列表,格式如:
关键字:XXX,YYY,ZZZ,……
这样可以弥补你的摘要篇幅,有关键字列表也能体现出你的专业,说明你是经常写此类技术文档的,关键字不应太多,单个词不要太长,3-5个关键字,每个2-6个字即可。
摘要应包含你的项目的主要内容,但不要罗嗦和过长,或变成主要叙述项目经过;包含你的一些关键事例,同样不能变成这些事例的流水帐;包含你的中心思想和观点,不要过细,去描述你的技术细节;包含你的项目获得的成果,不要变成成果和数字报告,可以有数字,但如果该数字的专业性太强,还是建议不要出现,因为别人看不懂,可以这样写:XXX指标达到了世界先进水平或创记录的YYY数字。总之,什么内容都要有,但都不能太多,应将重点放在介绍自己的观点上。如:
本文主要讨论了XXX方面的问题(或围绕XXX方面展开讨论),作者作为在XXX方面从事多年的工作的(或有丰富经验的)研发人员(或项目管理人员),以其亲身经历的XXX项目为例(或在XXX项目中),提出了XXX观点,采用了XXX方法,其中主要有:XXX,YYY,ZZZ(具体观点、方法、实例的名字列举),获得了XXX的效果,达到了XXX的水平,(如客户满意,节约了项目时间和资源,获得了巨大成功,打开了市场,运行搞效稳定,达到了国内国际领先水平,被授予什么奖励等等)。
如果此时尚觉内容不够,可对中心论点(你自己的东西)进行展开,可以提一些细节和专业术语,如:
(换行)其中,XXX的观点或方法,是一种XXX的方法,或包含XXX,YYY,ZZZ哪几个组成部分或步骤,其围绕或具有XXX的技术等等。
最后加上关键字列表,就是一篇很不错的摘要了。
总之,所有的内容都要点到,但都不能具体:本文的中心论点是什么,你是谁,论文使用的项目是什么,你的核心思想或观点是什么,你采用了什么样的技术或方法,是通过哪些手段去实现的,你的左证有哪些,最后该项目的结果是什么,有什么成效。如果篇幅允许,可另起一自然段对具体技术和思想再进行更详细一层的描述,应重点强调你自己的内容,而不是流水帐。
摘要中不要使用“我”这种第一人称,应使用官方的语气,不应出现你和你公司的名字,对项目名应加引号,对关键的专业术语和技术名称也应加引号以示强调。
切记不能套用或照抄题目,不能招抄问题的内容,反正不要从题目中寻找素材。
结构
总体上的正文结构应采用三段式,但你不要真的只有三个自然段。
第一部分,包括自我介绍和所在公司介绍,但不要出现自己和公司的名字,也不要用“我”;包括具体项目背景和简单描述,不要过于详细,或把整个项目过程都写出来;引出论题,这三部分内容。可以通过公司介绍来引出项目,再从项目介绍引出论题,最后必须出线论题,否则视为失败。如:
本人是一名XXX开发人员或管理人员,从事多年XXX方面的工作,现在为XXX公司工作,该公司主要有XXX样的产品或主要从事XXX的业务,其中另作者印象深刻的是XXX项目,该项目是……(进入介绍项目背景),其中作者作为主要的参与人员,主要负责其中的XXX工作,其中XXX是该项目的重点或最值得讨论的问题,作者从中在YYY方面获得了很大收获或重大启发(YYY就是文章题目)。
第一部分应控制在半页纸内容左右为佳,应避免过多叙述项目内容,后面还有机会,应注意不要过于明显与死板,阅卷人对你的项目内容不感兴趣,不要机械地去叙述项目的过程,你不是在交代问题。还有,不要为了凑字数,你最后只会感觉纸不够用。如果内容较多,应分为几个自然段,如个人与企业介绍,项目背景介绍,引出论点和基本论点申明,可以分别做为一个自然段(共三个自然段)。
第二部分,论文主体,在这里应解决这些问题:项目中设计到给论题的细节,采用的技术和方法,你的观点或你设计的方法,你总结出的经验,围绕这些论点进一步的论述,举例继续说明,典型中学议论文写法,很多,后面再说。
第三部分,项目的结果,获得了什么样的效果,不应过于夸大,应包括:项目的结果;还有哪些不足之处,必须要有;对论点的总结;以及对未来的设想,与改进之处。不写不足和缺点是愚蠢的,但不要在关键点上找缺点,应在项目的次要方面,如你重点是说设计的,就可以说性能的缺点,但不能说性能的缺点是因为设计不合理导致的,注意不要自相矛盾。
在这里可以列举一些数字,可以更好地说明问题,但注意报告成果的篇幅不应过大,此部分应不超过半页纸内容。至少应分两个自然段,先写项目结果,后写不足和设想。
一头一尾是最容易写多而影响主体内容比例的,应遵循简单的明白的原则。
主体
不要将整个项目过程都写出来,即便你的题目很大,可以覆盖整个项目,也应只取项目中的一个环节来写,如:需求分析阶段,系统设计阶段,测试阶段,软件某一部分所采用的技术等等。对于论题也不要面面俱到,应重点只讲属于论题范畴的一个论点。
不要将主要篇幅用来论述大家都知道的东西,如书本中对论题的描述,按照书本原样照抄一边,或去解释一些众所周知的技术内容,如B/S和C/S架构的定义,这些都是废话,应一笔简单提到或根本就不写都是可以的。也不要只谈项目细节而完全不写论点,如出现连续的篇幅长时间只在谈项目的内容,尤其不要以完全叙事的方式去写。
主体基本上应以提出问题,分析问题和解决问题三个部分去写,在第一部分可以主要描述细节,应以引出具体的问题而提出理论问题或核心论点为目的;可以偏重项目描述,只在最后提出论点即可;也可并重,一边叙述项目细节,一边逐步引出问题,最后引出你的核心论点。在这一部分可以完成对项目细节的补充的描述,如果认为前面的项目背景介绍不够的话。
第二部分为分析问题,应围绕核心论点展开,可选择两种展开方式:一种是以核心论点或主旨为中心,平行展开,如论点可以分为几个方面,可以就一个方面为主重点论述,也可各个方面并重论述;另一种是逐层递进式展开,以基本论点为起点,引出更深层次的问题,再引出再深一层次的问题,最后引出你真正想论述的问题,进行详细论述。此部分应以理论论述为主,还应适当地穿插实际佐证或例子,如在其它项目中遇到的问题,或在此项目中的细节,但都应简单和自然,不应给人以又开始叙事的感觉。永远记住你写的是议论文而不是记叙文。
第三部分应以得到结论和总结观点为主,如果你重点论述的是论题的一个分支,通常都是,应再回到论题上,起到画龙点睛的作用,即点题。此部分也是理论再返回到实践的过程,应以一定篇幅去介绍项目中的问题是如何在你的论点的帮助下得到解决的。可以以两种形式写:第一种,先总结论点,然后根据论点理论作用于项目,说明项目中的问题获得解决;第二种可以先描述项目解决的过程,方式,方法,技术等,然后总结出你的最终观点。
总之,提出问题应以描述具体问题为主,但该问题必须与论点相关,并引出论点即可;分析问题应以讨论和分析论点为主,可以将项目中细节逐个那出来举例,但应以理论描写为主线,具体事例与细节是穿插;解决问题应以项目的解决过程或方法,和论点总结并重,即可以先事例后观点,也可以先观点后事例。主体部分再简单也应有三个自然段,其中可根据篇幅需要合适分段。
论点
应以项目中的某一环节或软件系统的某一部分说事,在这个点上可以写的很具体,论点应服从大标题的范畴,但仅是大标题的一个方面或一个要点,应以自己在这个点上的独到观点为核心,以公认论点为准绳,应相互结合,要以自己的观点为主要论述对象,但不应偏离公认论点的主旨。即你是公认论点中的一个特例,或具体化的观点。以我写过的考题为例:
在“自动控制的人机交互技术”中,我将论点引到软件界面的设计这个方面,然后实际重点论述的是一种界面与模块分离的设计思想,再反过来说明这种设计方法给界面和用户带来的好处。就实际论点而言,有一点远,但我事实注意点题,并最终以说明给人机交互体验为最终目的,这样其实属于系统设计和模块化设计的内容,套上这个标题也很自然了。
在“论软件可行性分析”中,我以具体项目决策阶段的分析为基础,描述的是对这个具体项目的可行性分析过程的细节,主要说明了使用对比和排除法来获得决策的事例,就原理本身是很简单的,就是对比法和排除法,因此我把重点放在了如何用这两个方法来获得决策和可行性结论的具体过程上,其实就是对如何使用这两种方法的论述。因此它不是提出了什么新的方法和观点,而是简单方法的使用实例。
在“论系统软件的可靠性设计”中,我将论点引到服务端软件的鲁棒性设计上,重点论述的是一种服务软件的容错性设计,主要是如何保证软件在异常情况下的继续运行和自动恢复的方法,其中列举了很多这些方面的具体措施,方法很多,但我只选择了其中几个来重点描述,其他都是比较简单的介绍一下而已,最后的关键还是主旨,即核心目的应强调在错误中保证继续运行的这个目标,这仅是软件可靠性设计的一个方面而已。
注意事项
正文首行应空四格,然后写你所选的论文标题,不要不写,小学作文写过没?都要有标题。也不要自己再起个名字,注意审题,题目已要求你以此为题,也不要有副标题。
通篇都不能出现“我”,应以“作者”,“本人”代替,同理不应出现口语化文字和语气词。应以第三人称角度去写,而不是第一人称,也不要出现“作者想”等心理活动。
不能出现你自己或公司的名字,可以出现项目名字,体现项目的真实性,即你不能透露与你真实身份有关的提示,以免有作弊的嫌疑。不要体现出你是学生,如你的项目是在校期间完成的,那最好不要提学校的字样,或者干脆不要以次项目为例。
不能出现项目中的人物对话,这不是小说。
不要去抄题目中的一些内容或论点,那是一种愚蠢的行为,总之不要将题目中的任何东西作为你的素材。
不要去写一些大家都知道的事,或纯粹是书本中的内容,如用很大篇幅去论述一些书本理论,和经典理论,而自己的观点却很少,应正好相反,以论述自己的内容为主,以书本理论为轴心。也不要离题太远,完全脱离标题,完全是在写自己的一家之词,应围绕论题写自己的东西。
对于公认的论点,不应使用“作者认为”,而属于自己的观点,应使用。对论点,应使用“认为”这样确定性的词汇,而不能使用“想”,“觉得”这种模糊的词汇。举例,对于公共论点,有:“软件工程认为:……”,“软件测试的一项重要原则就是:……”;对于个人论点,有:“作者认为:……”,“作者根据XXX事例总结出一条规律:……”,“……从而严整了作者的假设或观点:……”。
文章注意留白,应将字数控制在最后一张纸留一半左右,不要再要求加纸,字数不能过多,也不能太少,写的多没用。如果半路发现时间来不及,应立即结束当前自然段,依次写主体的解决问题部分,简单写项目结果,简单写未来的展望(缺陷不写),保证有20分钟时间写摘要。如果时间更紧张,应先完成摘要,然后再写完正文。
发表于 @ 2007年09月25日 10:29:00|评论(loading...)|编辑