系统分析师-软件水平考试(高级)-开篇

系统分析师-软件水平考试(高级)-开篇

前言

时隔一年,我开始了系统分析师的博客写作。回过头翻看一下,一年前的系统架构设计师系列的第一篇博客-需求理论,还是比较有感触的。

其实系统分析师的考试早在上边年五月份就参与了,也在六月份就知道自己通过了考试。但是一方面系统分析师与系统架构设计师有很多内容上的重复,另一方面自己确实工作也比较忙,所以相关的博客就搁置下来了。

正好最近有点空闲时间,正好一方面整理所学,一方面输出一些博客,帮助大家。

分析师与架构师

首先,就是探讨一下,系统分析师与系统架构设计师的关联与区别。

两者都是软件考试的高级考试科目,并且也是相似对最高的两门高级科目。毕竟早期软考只有系统分析师的考试,而系统架构设计师是由于系统架构设计内容不断增多,然后分离出来单独成为一个科目的。

很多朋友都无法把握住两门考试科目的区别,导致学习无法集中注意力,从而造成考试失利。

考试角度

首先从考试角度来说,系统分析师中有关架构的部分,分值比较低,可以说几乎与企业信息化等章节一样,就是个普通公民,不再享受系统架构设计师考试中一等公民的待遇了。其次,系统分析师由于在架构方面的分值大幅下降,所以提高了所有章节的分值。简单说,就是所有章节的考试内容变多了。虽然深度不再深挖,但是考试范围的扩大,导致考生觉得系统分析师内容太过繁杂,准备困难,难以把握重点。

那么,分析师有没有类似架构师的重点呢?答案是有的。从考试的分值散布(客观,案例,论文综合起来看),以及考试名称——系统分析师,可以知道重点在分析。就像系统架构师的重心在架构,高项的重心在管理,分析师的重心在分析。当然了,由于系统分析师的特殊性(所有高级科目的源头),所以它的重心不会如架构师,管理师那样突出。

那么落在考试章节中,分析又落实在哪里呢?那就是系统规划,需求分析,以及一些零散的涉及分析的内容。当然,如果你是第一次参与高级考试,可千万别只看这两个章节啊。

现实角度

老规矩,从考试的角度分析后,我们来从现实角度分析一下。当公司规模不大的时候,公司技术方面往往就一个技术部。技术部会有一个负责人,他会负责所有技术相关的问题,包括但不限于:

  • 技术顾问:负责解答公司高层对技术的疑惑
  • 技术评估:参与公司项目,产品的技术评估
  • 技术规划:为公司的战略目标,提供技术方面的长远规划
  • 技术管理:为领导的技术部门进行有效管理
  • 技术支持:为领导的项目提供技术的直接帮助

公司规模不大的时候(百人以内,技术部门二十人以内),负责人尚且还能支撑得住,能够在各方,各个工作间周转开。不要问我怎么知道的,问就是我在上家公司就是做这些的。

但是随着公司规模增大,技术部门的人数增长。技术负责就不可能面面俱到了(某些牛人,就算了,咱只说正常情况)。

到了这个时候,原有技术负责的工作必须进行拆分。在中型公司,比较常见的是采用矩阵型的组织结构,原技术负责的职责拆分为:

  • 技术总监:负责技术顾问,技术规划
  • 项目经理:负责项目管理工作
  • 技术负责:负责单个项目的技术支持,配合项目经理与技术总监,完成技术评估,配合技术总监完成技术规划的落地。

(这其中的需求,往往是三方的协调,妥协的一个结果。如果不懂得这句话,可以等到我开启项目管理的分支,再细谈。或者私聊我)

不要问我怎么知道的,问就是因为年中有一个以前的上司来挖我的时候,和我提到了他们公司的情况。

可能你们要说,还是没有看到系统分析师啊?别急,马上就到了。

随着项目规模的扩大,项目内的技术负责压力就比较大了。一方面需要技术上司,业务方,项目经理打交道,了解具体需求,进而进行分析,另一方面还需要进行项目信息系统的架构设计,搭建,为下属提供技术支持。所以,部分大型公司就再次将技术负责拆分为业务分析师与技术架构师,也就是大家说的BA和架构师。不要问我怎么知道的,问就是这个月,打电话挖我的公司就有这么做。当然,也有人注意到,需求这个东西不是应该交由项目经理处理嘛?怎么说呢?一方面,有些需求只有技术人员才有那个敏感性,另一方面,项目经理虽然也有获取需求这一过程,但并不表示只靠项目经理自己去获取,更多的是需要依靠具体的人落实,后者具体的人配合落实。项目经理本身更多是一个协调整合的人员,而不一定就是具体落实的人。

学习必要性

可能有些朋友就要问了,大型公司才用到,那是不是对于很多人来说,这个考试的学习就没有意义了。

当然不是。

首先,即使是在中小公司,分析师的学习会补全架构师在业务方面,商业层面的不足。在一家中小公司,一个几乎只会谈论技术的(虽然有着非常高超的架构水平,但不是每个公司都有“伯乐”的)与一个可以谈论公司业务,可以为公司战略发展提出一个考虑了商业内涵的技术方案的,相信后者会更得Boss的欢心。

其次,不想当将军的士兵不是好士兵。不想去大公司露一手的,不是好员工。人嘛,总是要有一颗上进的心。

最后,我们需要提升自己视野,如果只局限于技术的维度,很容易把自己的职业道路走窄了。举个例子,马云评价行癫,不仅有足够的技术,更有着敏锐的商业视野。后面的故事,大家也都知道了,行癫上位(甚至现有的公司纷纷提出公司组成要有八成的技术人员,也不知道有没有这方面的原因。囧)。

学习困难性

分析师学习难不难?

从数据角度。系统架构设计师的考试就比较困难了,其通过率接近8%,而分析师的通过率就只有系统架构设计师的一半不到,其通过率约为3%-4%。

从内容角度。套用一位老师说的话,从内容的深度而言,分析师的内容深度与系统架构设计师差不多。但是内容的量级上,分析师的内容量级比系统架构师要多(大概1.5倍吧,但是如果从架构师转过来的话,只需要再学习0.7左右的内容)。

从抽象角度。对于有开发经验的人而言,架构师中提到的技术,以及架构思想,起码在经手的项目中能够比较直观的感受到。而分析师提到的系统规划,需求分析等内容就不是每个开发人员能经手到的了。当然,对于没有开发经验的,那么两者几乎是没有什么差别的。

XMIND

给出一个XMIND,让大家比较直观地感受到系统分析师的知识体系。

学习方法

那么有没有什么办法可以提高学习效率呢?

当然是有的。虽然我在架构师考试博客中推荐了许多书籍,但是分析师的书籍真的几乎没有,所以就不推荐了(毕竟也有一些人认为没有时间看那么多的书籍)。

说一下我的学习方法:

  • 首先,看一下教材的目录,了解往年考试情况与分值分布情况。然后有目的性地快速看一遍教材,不求甚解,只求留个印象。
  • 其次,配合XMIND,写下各个章节的重点内容,从而建立知识体系(我十分看重建立知识体系,包括面试别人的时候)。
  • 然后,配合XMIND,按照重要程度,去细看教材。不大清楚的地方,还会查阅资料,询问群友什么的。
  • 最后,就是做题啦,每个章节学习完,都会做章节练习,判断自己对这一章节的认识,并了解题型。另外学完所有章节(起码是自己认为应该学习的章节)后,还会做模拟题(尽量还原出考场的感觉)。最重要的,别忘了错题集,真的有用的。

总结

如果你想要参加考试,第一件事情就是需要明确自己是为了知识而来,还是为了考试而来,抑或是两者都有的。

另外,我这边确实有一个关于系统架构师/分析师的群,但是是邀请制的,也就是说给你群号也没用。如果有参与考试的想法,可以私信@我。

最后,只想说一下,软考高级是个好东西,但是也不可能让你立马上天的。它只是一个加速器,一个倍增器。就像架构师的考试,给了我一个很好的知识体系,虽然非常空荡荡的,但是我可以不断向其中填充具体的技术。目测架构师考试的红利,我至少还可以吃个三年。至于后续的分析师与管理师就更不用说了。最重要的是提供了非常好的视野,而视野这个东西,无法直观地带来薪水,职位的提升。但是这个东西的好处真的很多,关键其它途径很难如此快速地获得它。

最后,希望我的博客可以为大家提供帮助。谢谢。

posted @ 2019-11-18 09:05  血夜之末  阅读(...)  评论(... 编辑 收藏