如何成为一个好的系统分析员_软件工程

truely眼中的设计定义：设计的过程就是将事务处理抽象成计算机模型的过程。

　　1. 首先要明白设计远比编程重要。

　　2. 平时注重练习自己的思维严谨性和从全局考虑问题的能力。建立冷静思考问题的处事态度。

　　3. 设计时（尤其是数据库设计时）不要完全被规矩约束，设计好比作诗，懂得韵律是对的，但完全被韵律所束缚，就作不出好诗了。

　　4. 多做设计，经常总结自己的不足之处和成功之处，向他人请教。

　　5. 专门去找别人设计的漏洞和不足，也是提高自己设计水平的重要手段。

　　（记住：这个好方法不要顺便外传，自己知道就行了，嘻嘻-:）

　　6. 经验是重要的，但假如观念老化而不善于总结提高，所谓的经验就成为束缚自己进步的枷锁。

　　7. 学好数学非凡是理论数学如数学分析、运筹学、数学模型等。多玩策略性经营游戏也是有益的。推荐《帝国时代》和《模拟首都3000》以及《大富翁4》。（但不要沉陷在里面）

　　8. 根据项目情况和开发平台工具的特点确定最佳的设计方法。模块化设计方法和面向对象设计。两种设计方法的结合使用。

　　9. 将复杂无序的过程用模块化的方法进行分解，但要注重事务间的联系，并且用开放的眼光去设计。

　　10. 设计时对严谨性、灵活性、开发效率、客户要求四个方面做衡量取舍。

　　11. 设计时还要根据整个工程的进度安排和客户对软件的要求而决定是否设计得足够灵活和严谨。

　　12. 复杂而无条理是最糟的设计，简单实用并不一定是最好的，但一定不是最坏的。（不要说我偷懒哟）

　　13. 练习自己良好的表达能力，能用清楚明确而且简单的描述表达出自己的基本思路。

　　14. 在一个项目中建立统一的系统分析模式和文档模板，同时，一个项目中必须至少有一个人对整个系统设计进行检查和进行全局的考虑。

　　再谈如何成为一个好的系统分析员？

　　bylsfboy

　　系统分析员基本功：

　　好的系统分析员都是从优秀的程序员中产生的，坚实的编程功底、丰富的经验是今后做系统分析的基础。

　　没有对系统本身进行过透彻剖析过，很难领会到其中一些难以言述的精华。但并不等于好的程序员就能够成为好的系统分析员。

　　合理的知识结构。语言能力、文字表达能力、技术的全面性等是对系统分析员的基本要求。比如说c/s和3层开发，假如仅仅对netscape公司的产品熟悉还不够，还需要了解比如微软等产品，并且要了解他们中产生历史,发展思路，技术优劣，以应付各种穷追猛打的提问。但更重要的是，这是你为应用定制技术要求的前提。

　　系统分析员思想：

　　全局观念是系统分析员必须具备的观念。假如系统分析员设计时太注重细节，往往会陷入在某个问题上纠缠不清的泥潭。（93年，我论文指导老师的一席话影响了我随后几年对软件开发的理解----今后计算机会越来越快，多写几行代码少写代码无关紧要，最重要的是整体；一开始就错了，某个部份编得俸茫彩?nbsp;没有用的）

　　任务难度的猜测能力

　　系统分析员要具备快速的任务难度猜测能力以及具备快速确定开发小组人员构成和任务划分的能力。（我将这条归为思想，而不是能力）昆虫自然会长出翅膀，而思想却需要长期的浸润。要做到这点，需要大量的思考、学习。设计远比编程重要。当今软件业的发展，各种开发工具的出现，编程已经不是什么问题，

　　程序员的工作某种程度上讲是将别人现成的东西拼凑堆砌起来。系统分析员要清楚的熟悉到，现在大多数程序员没有学会怎么去整体的了解一个系统，有些甚至不了解编程（这不是说他们不会写代码）。可视化的开发工具加五花八门的控件，程序员可以偷点懒了。（这可不是夸大，我好几年的治理工作，接触过大量的程序员）基于技术，跳出框架。基于现有技术结合用户需求思考问题，设计时跳出框架。

　　系统分析员思想：

　　系统分析员要有面向用户的思想。系统分析员应当有能力将自己扮演成用户，来了解要交付的项目看起来想什么样式，感觉想什么，从而了解用户的想法并挑选出合理部份去开发。从这个意义上说，系统分析员才能获得有意义的见解去引导他的开发组成员。系统分析员头脑中要对项目结局有一个清楚的熟悉，并保证项目不偏离方向。系统分析员要有根植于技术，高于技术思考问题的思想。纯粹的程序员通常对最终结果考虑的不是很多，当一种新的技术在市场上出现时，他们对能否按时交付的考虑就比较少，而强烈希望他们的计划能够建立在新的技术之上。因此，系统分析员的想法和行动要象一个用户，又要能够站在技术的高度，成为真正的用户、程序员之间的代言人。

　　系统分析员的要害

　　获得信任。系统分析员最重要的素质是获得信任，这是成为优秀系统分析员的要害。成熟最为要害。成熟可以为整个项目组提供正确的支持,能够理解技术怎样才能解决用户的需求。

　　系统分析员的预备工作

　　统一的各种文档模式，这其中包括今后软件变量、字段命名规则。我推荐用pb制定的规则做基础，通过改造成为适合自身实用的标准。统一的文档治理。统一的分析软件。比如说rose（uml太规范，国内的软件治理水平根本用不上，只不过尽量应用，你自己对系统分析的理解有好处）

　　方法是思想的放映，在具体方法上就不多说了。我托人从u$a弄到几本书，用于面向对象系统开发的使

　　用》、《面向对象的分析》、《项目治理》等都是很不错的，推荐大家看看。

　　我在拙作“在中国没有人懂计算机“里发了点牢骚，听说挨了部份人（习惯性的）骂。其实，bbs本来就是发泄的地方，在这里从来就罕有有内容的文章。自从“维纳斯“登陆深圳后，大家更着眼于从宏观看中国的it业了。中国it这棵小树，说实在的，长到今天实在是不轻易。一些人提出了“反对微软霸权“的口号，不少人呼唤中国“硅谷“的出现。微软的成功不是技术的成功，更多的是商业运作的成功。

中国it这棵树能长多高，取决于他所植根于的土壤。而现在的事实是，这片土壤实在是太贫瘠了！假如按我们现在的思路和搞法，是长不成大树，更别指望能结出“微软“，“硅谷“这样丰硕的果实。假如说，我们的软件技术落后美国十年，我们的硬件制造技术则落后美国二十年，我们的治理水平落后美国至少三十年。而最终决定发展速率的恰恰是我们的死穴──低劣的治理水平。低劣的治理水平的形成的原因有着深厚的背景和多方面的原因。

　　系统分析工作是解决一个问题的工作,目标是将一个对计算机应用系统的需求转化成实际的物理实现,其中复杂就复杂在实际的面太多.在系统分析过程之中注重问以下的问题,可能会所进行的系统分析设计工作有帮助.

　　1)您所完成的系统目的是什么?注重不是功能要求,而是目的.也就是为什么要建设、为什么要现代建设。

　　2）您所完成的系统有哪些方面参与，各方面的初衷是什么？那些人可能在系统建设中起重要作用，他们会采取什么样的态度？你对他们有多少影响力？

　　3）您的系统是否有一个明确的评价标准？最好从参与的各方面都进行考虑。

　　4）你的系统设计思想是什么？是否能够得到各方面的认可。

　　5）你对参与系统设计开发的人员了解吗？他们的特长在哪里，是否愿意与你合作，为什么？你对他们有足够的影响力吗？

　　6）你的系统开发计划是否完善？你的计划表有明确的阶段吗？任何一阶段都应该怎样完成？如何对这一阶段完成的情况进行评价？

　　7）你对所采用的系统开发方法以及工具是否熟悉？你的夥伴是否熟悉？

　　8）你所完成的系统是否有原型？计算机的或者物理的。

　　以上的几个问题都是在系统分析以及系统规划时涉及到的，供各位参考。

　　这文章很好，我的话是：“需求分析实际应该是问题分析“。含义是系统要解决的是问题。而不是用户提出的需求。经常发现系统完成后，客户说“我的问题还没有解决“。可是，需求分析稿上的目标都搞定了。

　　既然是问题分析，所以，熟悉目标系统的知识就是必要的。甚至，可以说，一个好的系统分析员也应该是好的业务专家。

　　我很兴奋在这里碰到许多分析高手，可以交流分析中的问题。我赞同从来的观点。在中国作分析重要的是人气，因为中国的企业级信息系统的建设在很大程度上可以说并非确有需求，而是迫于某种压力。用户在很多时候考虑的不是系统的长远发展，而只是短期的成果，要求开发单位在很短的时间内完成一个很大的系统的开发，没有时间对系统进行周密的分析，在这种情况下，很多开发商就会粗分析，粗设计，尽快进入编码阶段，这样的系统的生命周期肯定不会很长。说了这么多，只是想说，系统分析员确实应是业务和治理专家，并且需要有很好的语言组织能力，他需要根据问题域中存在的问题去尽力说服用户，引导用户需求，究竟，我们是专家，假如让用户牵着鼻子走，系统不会是成功的系统。（当然了，这要建立在用户是可引导的前提下）本人拙见。

　　在理解和分析用户的需求时，应说服用户明白：建立计算机应用系统并不是简单地用计算机代替手工劳作，它更应该是治理思想的一次革命，是现用户模式的一次升华和提高。假如系统不能高于现实，开发的系统将长期陷入需求的反复修改，其软件的生命周期也短了。

　　针对我对您的问题的理解,试着作如下一般性/理论性的回复:

　　需求分析(您可以采用usecasedriven的方法进行需求分析)在明确需求分析的基础上,确定需要采用的系统分析方法(结构化/面向对象/构件式)应用您的开发团队所确定采用的分析/设计方法,进行系统分析.根据您所采用的分析方法,依次或反复进行系统设计/建模.

　　任何一套软件系统的模型的建立,是必须的根据所建立模型的性质上,依次或反复进行系统实现题是这样

　　的，我用pb编程已有一年半时间，其间也做过7，8个程序，有自己独立开发的，也有和别人合作完成的。

　　大部份都是与用户谈一谈，了解了用户的基本需求后，就立即开始编写程序，其间顶多有不懂的地方再向用户了解情况，直到编程完成。从来也没有想过什么别的，就算有文档一类的东西也多是编完了再写。但往往事后维护量非凡大，用户反映缺少功能，或者认为遍出来的东西并非他所想要的。虽然最后都完成了，但感觉非凡费劲。也看了一些软件工程方面的书，但总感觉不实用，因此想看看别人是怎样做的，是否自己看书方法不对，没有把握系统分析方面的精髓。
同时我感到自己长期以来，在编程方面没有丝毫进步，是否与没有理论基础有关。