做自己的系统分析师
原文：http://www.98exe.net/Article/d/2006-06-19/1759.html
这几天我在看软考的《系统分析师教程》，六百多页的书看了两百多页，现在感觉心里很复杂。再加上前几天和以前几个要好同事聚会，谈到软件系统的设计时有些争论，让我不得不写些什么。希望此文能以此文同中国从事软件开发的同行共勉。
前言
说来很不巧，我毕业于四川外语学院，没有受到过大学里面正规计算机课程的教育，在软件设计上的所有技能，基本上都是学习人家的代码，和看微软网站上的那些TechNotes。当时之所以选择英语院校，希望读懂人家的技术文档，是其中的一个原因。毕竟从现在很流行的Windows到Unix，他们的技术文档大都是英文写的。扯远了，其实开发一个好的系统，看懂有价值的技术资料是一个因素，更重要的因素在于对系统的分析和设计。
由于自己没有受到过真正的计算机方面的理论教育，所以最初，在进行软件开发的时候心里面特别没有底，在写代码的时候，我都特别小心，生怕写出来的程序在结构上不合理，执行效率低下。工作了一段时间，开始自己设计软件的系统的一部分，当时又怕自己设计出来的系统在结构上不合理，使后期开发无法进行。所以，我一都在思考软件的设计方法，不断的总结。
一直以来，我把系统设计、分析看成是一件很神圣的工作，虽然自己很早听说过有这样的考试认证，但是还是没有去报名，甚至没有去买考试用书。其原因就是我认为自己应该先多写代码，多接触工程实践，多积累一些经验，然后再来接受系统分析的工程方法。而现在，我在这行干了五年，我想我的经历应该可以让我来接受正规的系统分析方法了吧！ 所以，我要把我学习的过程和我以前在工作中对系统分析的一些经验写出来，希望大家批评、指教！
第一篇 系统分析到底分析些什么
一句话，系统分析就是“分析软件系统在它的生存周期与生存环境中，各个对象与它的关系 ”，记住是关系，这是我这几天看书，然后结合自己的开发经历所得出的结论。
一个大型的软件系统，它所涉及的关系多，所以这个系统做起来就复杂；一个小的软件，它所涉及的关系少，所以这个软件做起来就简单。但是在通常的情况下，这些关系需要系统分析人员去发现，通过各种手段：翻阅资料、采访相关人员等等。如果越多的关系被系统分析人员发现，那么系统分析员对系统的设计可能就越全面，系统结构对未来的不确定因素的适应能力可能会更强。
在这里，我一直在强调“可能”。在我开始思考系统设计之前，我就觉得只要我掌握了正确的系统分析方法，那么我设计出来的系统在结构上是最合理的，在性能上是最稳定的，这个系统近乎是一个完美的系统。现在看来，这种想法很幼稚，作为对关系的分析，本身就和个人的经验、价值观有直接的、非常紧密的联系。所以我们要正确的对待系统分析师这个职业，他不是神，他只是一个将系统的开发风险尽可能降低到最低的人。
第二篇 如何分析
并不是每个公司都有自己专门的系统分析师，但是每个公司都有自己的系统分析工作，我想这是中国大多数软件公司所面临的现状吧。我们不能够因为没有系统分析师的存在，而把那些客观存在，需要我们去分析的东西丢在一边，最后只能是搬起石头扎自己的脚。
看了《系统分析教程》之后，让我对如何做系统分析有了新的认识，但是里面提到的各种方法，动不动就要小组支持，安排会议，这些活动档次太高，咱们平时做的那些系统玩不起，那是不是因此我们就放弃系统分析呢？答案是否定的。我认为，软件系统的规模有大小，系统分析的规模也有大小，不同规模的系统，它的分析方法也应该不一样，下面我把我分析的方法写出来，希望大家批评指教。
- 接到一个工程后，脑子里对这个工程大致有个数，然后就把开发工具打开，开始干了（这种方法很土，和软件工程方法是背道而驰的）。 但是，当代码写道一定程度的时候一定要停下来，你要对以做的开发做记录。记录什么呢？比如：重要的处理过程，窗体的名称以及它的功能描述以及你当时认为有用的东西。然后继续写代码。在后来的开发过程中，当你回复前一段时间写的代码而不能马上理解它的意思的时候，你就得马上记录。当软件快开发到一半的时候，这时你对软件的整体构架比较清晰了，你就得分析出软件的基础模块，回顾以前的记录文档，看是否有其它模块也拥有你分析出来的基础模块的功能，如果有，那么就得对程序进行调整。调整完成之后，你就可以继续后面的开发了，系统做到这个地步，一般成功的把握就有90％了。这种方法只适合于做规模比较小的系统，例如一般的进销存系统，功能比较单一的小软件。
后来我把这种分析方法命名为攀岩式分析，作为一个攀登者，需要的是力气和勇气来面对面前的大山，然后迈出第一步，攀登一截就打下一个钉子固定好，然后继续攀登，就算不小心失足，由于有前面的钉子固定，也不至于掉下万丈深渊。
在没有系统分析团队支持的情况下，这种方法可以在一定程度上降低软件系统的开发和维护风险
- 当拿到一个系统开发任务的时候，先整理出开发任务中的数据对象，然后然后分析他们之间的关系，通过关系的分析，找出隐藏的数据对象；确定软件的功能框架，根据功能框架，画出数据流图和控制流图；分析基本的功能框架，然后做出一个基本的系统，然后拿给“领导 ”看。
以上的描述是我碰到的真是情况后的处理办法，这个办法结合了结构化分析和原型开发中容易操作部分。
在很多时候，我们可能接到一个比较大的开发任务，而拿到手里的却是一页草草几十字的“需求分析”，并且可能是有问题的需求分析。因为那页纸上写的内容实际上也是系统分析范畴中的资料，但是里面却杂糅模块功能描述、数据实体描述、数据存储描述等等信息。而我们该怎么办，撒手不干了？
这时，首先要做的就是挑出里面的名词，将其做成矩阵，对有关系的名词打上标记，并注明是什么关系。在这个分析中，肯定会遇到问题，而我们要做的就是先把这些问题记录下来，这些问题最好不要立即去问“领导”们，因为他们可能也不清楚。
接下来要做的是根据那份“需求分析”，指定出系统的功能框架，分析出最基本的框架，然后从最基本的框架着手，对框架的功能作进一步分解，然后再绘制的数据流图和控制流图，在绘制数据流图的时候，提取数据实体，建立基本的数据库（如果需要使用数据库的话），当然这个做法和《系统分析师教程》中的提到的方法也是大相径庭的，但是没有办法，因为我们连对象之间的关系都没有弄清楚，哪里来的逻辑分析严密的数据实体分析呀，为了工作，硬着头皮也要上啊。
接下来就是按照上面的设计，把系统做出来，然后叫领导看，让领导多提意见，称领导在看程序的机会，顺便把押在手里面的问题拿出来，问题能解决多少算多少吧，然后继续开发，然后继续让领导审查，领导越高兴，问题解决的周期就越短，反之则越长。
这些都是我的土方法，是没有办法的办法呀，工作还要继续干，并且还要干好呢！
第三篇 是系统分析师还是程序员？
我本来打算把这篇的标题定为“系统分析师和程序员的关系”，在我看了两个网友的留言后，我决定放弃这个标题，一个网友评论说，系统分析师应该消失，因为现在的原型化开发已经让系统分析师失去了价值；一位网友评论说，他在一个七八十人的小公司里面工作，认为系统分析师存在的必要性很大，并且说如果没有系统分析师的队伍，可能会失去竞争力。我认为这两种看法都过于偏激，因为他们都没有考虑到，不论是系统分析师和程序员还是其它搞开发的人员，他们都是软件公司的一部分。
作为一个软件公司，作为一个企业，都有自己的生存法则，大公司有大公司的活法，小公司有小公司的活法。大公司实力大，人数多，能够接到大的项目，那么他必然要有自己专门的系统分析师团队来维护公司正常的业务运营；而小公司，通常接到的项目都比较小，人数又有限，要想支持一个专业的系统分析师团队是不可能的。我现在就在一个小公司里面工作，接到任务后，直接就和客户打交道，直接从客户那里获取他的需求信息，然后自己整理资料，分析系统的结构，然后编码，然后测试，这些事情是没有人来为我完成的。
所以我认为，系统分析师可以有两种定义：一种从职务的角度来定义：这个人是我们公司的系统分析师；一种是从专业的角度来定义：这个人具备系统分析的专业知识。但不管从哪种角度来定义，它们都具备同一个特点：他们都要完成系统分析的工作。
分析本身就是一项复杂的活动，它的复杂不仅体现在它所涉及对象本身，还涉及到指导分析的方法论。而这些都是通用的哲学，他同样可以知道我们在其它领域更好的开展活动。所以对于系统分析这项活动，作为一个程序员，也要去学习它，实践它，这对我们是有好处的。
所以，不管我们所处的环境如何，是大公司还是小公司，至少我们都应该做自己的系统分析师。
到此，有关我对系统分析师的感慨写完了，这篇文章只是我个人对系统分析师的看法，局限性很大，还希望大家多多指教。
本博客为学习交流用，凡未注明引用的均为本人作品，转载请注明出处，如有版权问题请及时通知。由于博客时间仓促，错误之处敬请谅解，有任何意见可给我留言，愿共同学习进步。