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

前言

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

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

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

分析师与架构师

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

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

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

考试角度

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

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

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

现实角度

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

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

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

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

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

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

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

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

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

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

学习必要性

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

当然不是。

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

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

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

学习困难性

分析师学习难不难？

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

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

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

xmind

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

学习方法

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

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

说一下我的学习方法：

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

总结

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

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

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

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